CODEWITHSUNDEEP
xpageslotus-noteslotus-domino
Michael Saiz
Michael Saiz

Reputation: 1640

Lotus FTSearch wildcard with Numbers and Dot's

Hi there i have a huge problem with my database.ftSearch.

Background: The database contains about 5k Dokuments with text fields only. One of the fields is called ArtId. For the search i use a longer query wich targets different fields but i tracked the problem down to this:

Problem: When i Search for a ArtId like 12345 i convert the search to [ArtId]="*12345*" allowing the user to find also 01234567 wich works pretty nice. But the problem is i also have dokuments where the ArtId looks like this 01.123.45. If i try to search this it also gets converted to [ArtId]="*01.123.45*" and that returns... nothing because . and * dont seem to work together.

If i use the search in the database i get the same results. Is there any escape for . inside a "number". I already tried to replace the dot with ? or other query params but nothing helped.

I knwo this is more a notes question then a xpages question but as i call this from an xPage maby there is an earlyer workaround to catch the . input and convert it inside my XPages code.

Upvotes: 0

Views: 713

Answers (4)

Michael Saiz
Michael Saiz

Reputation: 1640

Ok, i found the issue... After 3 times copying the Database and rebuilding the index it now works... it seems that the index in the database was simply broken.

I dont know why it didnt work the first times when i deleted and created a new index but now it works.

Upvotes: 0

Richard Schwartz
Richard Schwartz

Reputation: 14628

In FTSearch, the dot char is (probably) not being indexed since FTSearch is word-oriented and a dot is considered a word separator in normal text parsing.

You could use a non-FT search with @Contains(fieldname;"12345" : "123.45"). This will be slower than a FTsearch, but with only 3000 documents the performance may be acceptable.

Or, I believe you could use the "NEAR" keyword in FTSearch, as in "01 NEAR 123 NEAR 45", but you would have to do another pass in code over the result set in order to be sure you're not getting false positives from ids where the segments appear in a different order.

Upvotes: 0

Bill F
Bill F

Reputation: 2087

I do something similar to Ken's suggestion because I need to search on a multivalue field that contains a list of Fully Qualified names and a search for fieldName contains CN=Some Name/O=SomeOrg always fails, but if I create a computed field and convert the names to Abbreviated the fieldname contains Some Name/SomeOrg works correctly. The FTSearch is nice but it is very sensitive to some format issues. So I think your problem would be solved by creating a computed field puts all data into the same format.

Upvotes: 1

Ken Pespisa
Ken Pespisa

Reputation: 22266

One suggestion - you could create a computed field that removes the dot from the ArtId, and then do your wildcard searches on that item instead.

Upvotes: 0

Related Questions