Roy,

<< Sigh - I thought I'd finished work on my query generator and now I have
another check and bit to add - sigh >>

It's only an issue if you define the indexed columns with a different
collation than the source table column(s).   As I told Uli, if he had
defined the source column in the table with the collation DEU_CI, then the
collation specification in the WHERE clause would have been unnecessary.

<< ps is the section in the manual on optimisations new? >>

Nope, it's been in there since the beginning.

--
Tim Young
Elevate Software
www.elevatesoft.com

<<
It's only an issue if you define the indexed columns with a different
collation than the source table column(s).   As I told Uli, if he had
defined the source column in the table with the collation DEU_CI, then the
collation specification in the WHERE clause would have been unnecessary.
>>

To finish this discussion: The problem occured because I simply didn't know about the
necessity of defining the collation in the column. This didn't exist in DBISAM. Wouldn't
it be a good idea to set the collation according to a defined index (CaseInsensitive) when
migrating the tables from DBISAM?

Thanks again for your patient help.

Uli

Uli,

<< To finish this discussion: The problem occured because I simply didn't
know about the necessity of defining the collation in the column. This
didn't exist in DBISAM. Wouldn't it be a good idea to set the collation
according to a defined index (CaseInsensitive) when migrating the tables
from DBISAM? >>

I've considered it, but it has other implications that aren't so nice, such
as what if someone has a query that is using a row scan that he/she *wants*
to be case-sensitive ?  If I were to do what you suggest, it would result in
that query being "broken".

--
Tim Young
Elevate Software
www.elevatesoft.com