> Jason,
>
> 1. Searching with IncSearchEdit fails to correctly locate
> strings that have
> a minus sign in them. This can be easily tested for example with the
> following strings in a table:
>
> Andy Warhol Knock-Off Ltd
> Ad-Astra Corporation
> Ad Infinitum
> Adagio and Sons
> Beryl''s Beryllium Supermarket
>
> Searching for "adag" will correctly find "Adagio and Sons",
> but if you enter
> "adagio" as the search criteria, it will stop at "Ad-Astra
> Corporation"
> which is wrong.

There isn't anything more I can do about the sorting problem. You can
override the text comparison routine at the connection level to get the sort
order you prefer.

> 2. Setting a filter with a sub-query fails, because IBO
> parses the filter
> string incorrectly. I use this (well, would use if it worked) in my
> application to display customers belonging to given classes, where a
> customer can belong to many different classes so there is an
> intermediator
> table linking ID's of customers and classes. The filter
> string would be
> something like:
>
> id in (select customerid from custtoclass where classid in(1, 2))
>
> When I set Filtered := True, this causes the following
> exception to be
> thrown:
>
> Invalid syntax: extra or missing parenthesis:
> (
> id in ( select, customerid, from, custtoclass, where,
> classid, in, (, 1,
> 2 )
> )
> )
>
> Easy to see the problem, the extra commas between every word.
>
>
> Both these problems existed already in 4.6, and I reported
> them back then. I
> can repeat these with a sample application which I can upload
> to the files
> area if it is needed.
>
> Please respond. I have customers who have been waiting for
> these problems to
> be fixed for quite a while already.

I am working on a new sub-release and this issue will be resolved.

For the time being, as a workaround preface a direct SQL filter with ::SQL::
(see help file for exact syntax) and you can avoid IBO doing any parsing of
the filter itself. It will just patch in your filter as direct SQL in the
WHERE clause.


Jason