UniGrid Search supports powerful searches using a variety of expressions. We will give you an overview of their syntax in this topic. We are basing it on the documentation written by Tamarack Associates for their Rubicon component which Alventis uses for its full-text indexing needs.

 

Searches support the following operators (listed in the highest to lowest order of precedence):

LIKE, NEAR

NOT

AND, OR

Note that we are writing the operators in uppercase simply to make them stand-out from surrounding text, if any. The entire search text is case-insensitive, which applies to both literal text you are searching for and operators, so in "real life", a search for "Jack AND Smith" is equivalent to "jack and smith".

 

The following expressions show the syntax of each operator:

LIKE <string>

<string> NEAR <string>

NOT <expression>

<expression> OR <expression>

<expression> AND <expression>

In the above:

<string> is a literal string of text you are looking for, possibly ending with a wildcard character (e.g., maple, map*)

<expression> can be a <string> or another, simpler, expression, possibly enclosed in parentheses

 

This should become clear from some examples:

 

SearchWhat it looks for
mapleThe literal word (string) "maple"
 
map*All words that start with "map": map, maps, maple, etc.
 
ma*eWords that start with "ma" and end with "e": maple, marble, etc.
 
ma?leWords that contain any character in place of the "?" symbol: maple or matle, but not marble
 
LIKE mapleWords that sound like maple, e.g., maple, maphle (whatever that is). Like compares words based on their phonetic similarity using a modified Soundex algorithm.
 
maple AND leafText that contains both words anywhere
 
maple AND NOT syrupText with "maple" but not "syrup"
 
maple NEAR leaf OR flagText where either "maple" is found close enough to "leaf", or "flag" is found somewhere
 
maple NEAR (leaf OR syrup)Text where "maple" is found not far from either "leaf" or "syrup"
 
"maple leaf"The literal phrase – just as specified, except for quotes (i.e., it will find: a maple leaf fell from a pine tree).
 
(ma?l* AND leaf*) OR LIKE flaghYou should be able to figure this one out by now, but if not: text that contains either some word that resembles "flagh" (e.g., "flag") or, failing that, text that contains both some word whose first two letters are "ma" followed by any one letter, followed by "l", followed by whatever -and- any word that starts with "leaf".

 

As you may have gathered, you can use two wildcard characters:

* means "any sequence of characters" (or none)

? means "any single character"

You can freely mix-and-match them as you wish, e.g., *uto??b* would match "automobile" or "utofobia" (if such a thing existed).

 

You can enclose phrases or words you want to find in a particular sequence in double or single quotes: "good dog" is equivalent to 'good dog'. Whichever quotes you use, you must always make sure you match them properly, i.e., that you have proper pairs of quotes of the same kind. Same goes for parenthesis.

 

There's also one simplified type of search you can perform. If you don't need to use any expression operators, you can simply make a search consisting of a space-separated list of words, and the search will use the AND logic for them. For example, the following two searches are equivalent:

maple syrup pine

maple AND syrup AND pine

 

If you write a search that Alventis cannot understand according to the syntax described above, the search won't be executed, and Alventis will make the search text red as an indication of an error condition. This may happen periodically while you are in the process of typing your search. For instance, if the search you intend to execute is "maple AND syrup" (with no quotes), the moment you type "maple AND", the search expression becomes red indicating an error. This makes sense since the above expression is indeed syntactically incorrect. But since you know you'll "fix" it in a moment by adding "syrup" to it, you should simply ignore such transient errors.

 

There are two search types that are more time-consuming than the rest: searches where the expression starts with a wildcard (e.g., "*ortoise") and proximity searches (e.g., "slow NEAR search"). They may take on the order of 1 second per 1000 records, so it only becomes a problem for large tables.