Subject | JASON Re: [IBO] Incremental PROBLEM Search |
---|---|
Author | radevojvodic |
Post date | 2005-12-21T08:25:56Z |
I had similar situation and it worked for me in this way.
In TIBO_Query editor on Ordering tab after you create orders you want
you need to add COLLATE statement.
Description=DESCRIPTION COLLATE ES_ES;DESCRIPTION DESC COLLATE ES_ES
Rade
In TIBO_Query editor on Ordering tab after you create orders you want
you need to add COLLATE statement.
Description=DESCRIPTION COLLATE ES_ES;DESCRIPTION DESC COLLATE ES_ES
Rade
--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
>
> 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
>