I believe Jason created a hookup to any
ordering/compare routine of your liking.

Just a thought,
Hans
-----------------------------------------
Dieter Tremel wrote:

>
> Hello,
>
> I want to report that IB_IncSearch does not function well on VARCHAR
> fields with WIN1252 Characterset und Collation PXW_INTL. This is
> important for german users which have this collation because of
> historical reasons coming from BDE. I show example DDL at end of the
> post.
>
> In this Collation for instance German umlaut 'ä' is sorted like the
> pair 'ae', but the Function AnsiCompareStr that IB_IncSearch uses
> orders ä like a separate letter between a and b.
>
> As a result IB_IncSearch does not find record despite they are there.
> My workaround was to go to ISO8859_1 with Collation DE_DE which
> corresponds to AnsiCompareStr and all is OK, but it is not easy to
> transform all customers databases.
> Shure, another Workaround would be to use a own
> TIB_Connection.OnCustomCompareStr function with is like PXW_INTL, but
> should TIB_IncSearch not take care of the collation order? At least
> there should be a hint in the help.
>
> Thank You Dieter Tremel
>
> /*--- Metadata report ---*/
> SET TERM ^;
>
> /* Started at 27.09.2001 10:24:58 */
> /* Connect using owner = SYSDBA */
> /* Using server WI-V6.0.0.627 */
>
> SET SQL DIALECT 3^
> CREATE DATABASE 'SACDATA.GDB' DEFAULT CHARACTER SET WIN1252^
>
> CREATE DOMAIN NAME1_D AS VARCHAR(39) CHARACTER SET WIN1252 NOT NULL
> COLLATE PXW_INTL^
>
> /* Table List. 1 */
> CREATE TABLE ADRESSEN (
> ADRESSNR PRIMKEY_D /* INTEGER */ NOT NULL,
> NAME1 NAME1_D /* VARCHAR(39) CHARACTER SET WIN1252 */ NOT NULL,
> ...
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/