hello Peter,

> Are you working with charset NONE or are
> specific charset and collation set for NAME?

yes, the default charset for the whole database is ISO8859_1. This a
partial extract of the DDL:

......... From file Database.sql:

SET SQL DIALECT 3;

CREATE DATABASE 'C:\SBSoftware\DB\Logstar\Logstar.fdb'
USER 'SYSDBA'
PASSWORD 'masterkey'
PAGE_SIZE 4096
DEFAULT CHARACTER SET ISO8859_1;
...

......... From file Collate.sql:

SET NAMES ISO8859_1;

CONNECT 'C:\SBSoftware\DB\Logstar\Logstar.fdb'
USER 'SYSDBA'
PASSWORD 'masterkey';

DELETE FROM RDB$COLLATIONS
WHERE RDB$COLLATION_NAME = 'BETA_ISO8859_1_NOCASE'
AND RDB$CHARACTER_SET_ID = 21
AND RDB$COLLATION_ID = 16;

INSERT INTO RDB$COLLATIONS(
RDB$COLLATION_NAME,
RDB$CHARACTER_SET_ID,
RDB$COLLATION_ID)
VALUES('BETA_ISO8859_1_NOCASE', 21, 16);

...

......... From file Domains.sql:

SET NAMES ISO8859_1;

CONNECT 'C:\SBSoftware\DB\Logstar\Logstar.fdb'
USER 'SYSDBA'
PASSWORD 'masterkey';

...

CREATE DOMAIN CH_CALL_SIGN
AS VARCHAR(30)
NOT NULL
COLLATE BETA_ISO8859_1_NOCASE; <-- this is your loadable collation driver

...

......... From file Tables.sql:

SET NAMES ISO8859_1;

CONNECT 'C:\SBSoftware\DB\Logstar\Logstar.fdb'
USER 'SYSDBA'
PASSWORD 'masterkey';

...

CREATE TABLE AT_Qsl_Managers(
ID_AT_Manager INT_ID,
Call_Sign CH_CALL_SIGN, <-- this is the field that gives the problem

...

......... From file Primary keys.sql:

SET NAMES ISO8859_1;

CONNECT 'C:\SBSoftware\DB\Logstar\Logstar.fdb'
USER 'SYSDBA'
PASSWORD 'masterkey';

...

ALTER TABLE AT_Qsl_Managers
ADD CONSTRAINT PK_AT_Qsl_Managers
PRIMARY KEY(ID_AT_Manager);

.........

I want to point out that the example of my previous message was purely
fictitious just to show the problem. The metadata of the full database is
far more complicated :-)

For now I have found only two cases where this error pops out, but maybe
I'll found others. The first 'real' query is:

SELECT ID_AT_Manager FROM AT_Qsl_Managers WHERE Call_Sign = '1AT683'

It gives the following 'real' and wrong result:

ID_AT_Manager
-------------
10
19

where:

ID_AT_Manager = 10 ---> Call_Sign = '1AT68'
ID_AT_Manager = 19 ---> Call_Sign = '1AT683'

and the second 'real' query is:

SELECT ID_AT_Manager FROM AT_Qsl_Managers WHERE Call_Sign = '1AT1688'

that gives the following 'real' and wrong result:

ID_AT_Manager
-------------
23
68

where:

ID_AT_Manager = 23 ---> Call_Sign = '1AT1688'
ID_AT_Manager = 68 ---> Call_Sign = '1AT168'

These results make no sense for me. This table may contain duplicated
"Call_Sign" fields, but not in this case.

But attention, now I execute again the two queries as follow:

SELECT ID_AT_Manager FROM AT_Qsl_Managers WHERE Call_Sign = '1AT68'

Gives the following 'real' and 'CORRECT' result:

ID_AT_Manager
-------------
10

ID_AT_Manager = 10 ---> Call_Sign = '1AT68'

.....

SELECT ID_AT_Manager FROM AT_Qsl_Managers WHERE Call_Sign = '1AT168'

Gives the following 'real' and 'CORRECT' result:

ID_AT_Manager
-------------
68

where:

ID_AT_Manager = 68 ---> Call_Sign = '1AT168'


I repeat that I don't remember a similar problem when I was using Firebird
1.03, but I have also to say that with FB 1.03 I was using Brookstone
collation drivers, while now with FB 1.5 I'm using your loadable collation
driver that you sent me some months ago (only BETA_ISO8859_1_NOCASE, no
other collations added as you can see above).

Regards
Salvatore