|
i just did a search for "UNC Drive" on SQLA2 -- and it took forever to return 0 results... I did the same search on SQLA, and it instantly came up with a bunch of results... and I found a very interesting question from Breck on NAS, SAN and Raid... which is part of the problem I'm working on. Nonetheless, this is not really a "Question" but not a rant either -- but just so you guys know, the search is not working right. Meanwhile, I hope SQLA 1.0 stays up until the search here is tuned up. |
|
The behavior you are seeing is due to the fact that SQLA2 is using the SQL Anywhere full text search feature, not the same search engine SQLA is using, with a different query interpretation. On SQLA, the query UNC Drive or "UNC Drive" finds the documents that contain either UNC, or Drive, or both. In fact, if you check the top matches for the query, none of them contain the string UNC. This happens if you use the search window near Links. If you use the Google search over the SQLA, no matching questions are returned. To get the behavior similar to the search bar near Links, convert your query to a full text OR query: UNC OR Drive. If you specify UNC Drive as the query, the server interprets that as UNC AND Drive, and finds no matching documents. If you specify the query as "UNC Drive", the search is performed for the exact phrase UNC Drive, so no results are found. Thanks Elmi... two comments... one is the speed. Is that recognized as an issue, or is it just me being impatient? ;-) The other is.. thanks for the explanation -- my natural course of any search is to assume that search terms are ORed together, with search results on top that match both.
(14 Mar '11, 16:54)
Ron Hiner
1
I will take a look at why the query takes so long to return. In case you were wondering about the language, this is a link to the documentation on the Full text search in SQL Anywhere: http://dcx.sybase.com/index.html#1201en/dbreference/contains-search-condition.html A colleague has just pointed out that UNC | Drive currently does not work, so I would use the keywords (OR, AND, NEAR) rather than operators (|, &, ~) for now. This problem will also be investigated.
(14 Mar '11, 17:11)
Elmi Eflov
Replies hidden
2
FYI we are still investigating the speed problem. Some of the SQL generated by the back end is not only suboptimal, but incorrect. The search returns the correct search results, but ends up scanning the text index a thousand times. So considering what it's doing, it's actually pretty fast! We are investigating the best way to clean this up.
(17 Mar '11, 16:04)
Graeme Perrow
|
|
While I understand the topic Elmi is dealing with, I'd like to point out that the SQLA2 search seems way superior to me, compared to the normal search box in SQLA. F.e. when searching for "sa_reset_identity", SQLA2 lists two appropriate topics (which I do know as the poster): However SQLA's builtin search lists none - it seems to strip the underscores from the search keyword and then can't find the proc name. And the google search within SQLA lists 12 topics but none of the ones SQLA2 lists (and none who seems to contain the search phrase). I guess a google search might be better for non exact phrases or synonyms and the like, but I have much more confidence to the SQLA2 search facility than to SQLA's builtin facility. 2
Just for the record - the procedure name, whether enclosed in double quotes or not, is treated by SQL Anywhere full text search as a phrase because the non-alphanumeric characters it contains are not space characters. You would get exactly the same results by issuing the query "sa reset identity" (double quotes required in this case, and, in general, recommended when your query is a phrase).
(15 Mar '11, 10:33)
Elmi Eflov
|
