Helen Borrie wrote:

> In Fb 2.1 - and we assume your database was created under Fb 2.1 - the
> identifiers are stored as UTF-8. It looks as though Flamerobin might
> have done the mangling, by re-transliterating the ISO8859_1 input to
> UNICODE_FSS, which is the charset used for identifiers prior to v.2.1.

Yes, that's entirely possible. They don't officially support 2.1 yet. :-)

I assuem the same applies to the odbc driver then, because I've had no
problems running queries from ASP via odbc with this database created
via FlameRobin.

> Why can't you test it yourself, using isql?

I can, of course, and no I have done so. All identifiers are "mangled"
where åäö appears. I can create the constraint using the mangled
identifiers. No use testing with non-mangled identifiers really, is there?

> The whole charset issue in Fb 2.1 is massively confused, at least to me.

To be honest I find the charset and transliteration in FB to become less
and less confusing. It was nice to know that all identifiers are stored
in UTF8.

Does FB store all character data in the system tables in UTF8,
regardless of the database's default charset?

I suppose it doesn't really matter as long as it transliterates correctly...

I think I would now like to conclude that FlameRobin is doing things
wrong in more than one place:

1. In most places it transliterates identifiers incorrectly, probably
assuming they should be communicated with FR in UNICODE_FSS as per your
suspicion.

2. It is inconsistent in that identifiers in the check constraint "body"
is transliterated in a different way than other places, e.g. select,
create table, etc.

I'll update my thread in the FR list.

Thanks,
Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64