Hi Jason,

Jason Wharton wrote:

> This capability could be added to IBO fairly easily. I'll
> look into adding it to the feature list. In short, we would
> need to agree on the rules for parsing out the search criteria
> and have it also be internationalized too.

> Suggestions for anything different here than what Jeff has
> proposed?

My problem with implementing this globally is that any special
characters you choose begin to expand on those things that are
"special" in the search string. Its like introducing a new
keyword into a programming language - something that should be
done carefully or you will upset what people have come to
expect.

The neat thing about the current arrangement (using BETWEEN and
IN etc) is that these are prefix strings that can be easily
circumvented by using '=' or LIKE or whatever to get the
effect you want.

The hyphen character ('-') is not that uncommon in various
names and similar texts, and as the sign in number texts. I
guess you could limit this interpretation to number and date
fields (where range is most common) and only use it if it
occurs between digits (not at the start or end). Another
alternative would be '..' which seems unlikely to occur in
normal texts.

As for the comma as a list separator, I am guessing that that
may be OK. I see where you currently support the use of
commas in an IN clause with numbers by using ', ' as the item
separator where the locale uses ',' as the decimal separator.
Similar distinction would presumably occur if you decided to
remove the need for the surrounding IN( ) text. If there have
been no objections so far then this approach could continue.


Personally...

I like the idea of something to make BETWEEN work better (but
probably with '..' rather than '-', it is so verbose at the
moment that it is difficult to use in small controls.

I dont really think it is worth it for 'IN'. It is not verbose
now and does not really need anything better.


--
Geoff Worboys
Telesis Computing