At 05:54 PM 15/12/2005 +0000, you wrote:

>Hi All,
>
>I have a column defined as DESCRIPTION VARCHAR(60) CHARACTER SET
>ISO8859_1 COLLATE ES_ES in one of my tables.
>
>Ordering in TIBO_Query works fine but incremental searching can't find
>my special characters.
>Does anyone have a solution to this problem?
>
>I know this is not first question in this way, but NO ONE cans solve
>or give some light about?
>
>Of course I set the character set on conection, and in the database
>all wotk fine, bu not in IBO inc_search.

I don't know the solution, only the cause...but you need some kind of
answer to this reasonable question! If Jason already answered it and I
missed it, my apologies.

The problem is that, to get a collation-sensitive search requires a COLLATE
clause in both the ORDER BY and the WHERE criteria, viz., the request sent
to the server would need to resolve as

SELECT.....
ORDER BY [OrderingItem] COLLATE ES_ES
WHERE Description STARTING WITH '<current input string>' COLLATE ES_ES

In other words, it needs to be possible for IBO's parser to consider a
COLLATE attribute when it is processing the OrderingItem and the string of
characters that it is going to search on. I don't know of any properties
you can set to make this happen.

One possibility I can think of is to define a proxy column in the table
with CHARACTER SET NONE, to which you write (with a trigger) each time the
Description column is written to, i.e. a BEFORE INSERT OR UPDATE trigger,
if you are using Firebird 1.5 or higher, containing

if (new.Description is not null) then
new.Descr_proxy = upper(new.Description);

And then set the column's NoCaseFieldName attribute in the ColumnAttributes
(or in the IB_Connection, if you prefer to set it globally), i.e.
In Fields Editor: Check "CASE INSENSITIVE" and enter name of
case-insensitive proxy search column in accompanying field.
In the Stringlist Editor (for the column, or globally, in the
ib_connection): [TABLE.]COLUMNNAME=NOCASE=MyProxyColumnName

I can't test this theory as I don't have any databases that use
collations. If you think it's worth a try, just do it with one of your
lookup tables and let us know what happens. You could add the proxy column
and the trigger, and immediately use the following statement to fire the
BEFORE UPDATE part of the trigger and update the new column for the
existing records:

update mytable
set Description = Description

Meanwhile, let's see whether Jason can offer some "trick" that is simpler.

Helen