At 09:49 AM 19/06/2008, you wrote:

>> 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?

No! for example, if you had a character search argument in your CHECK constraint definitiion, it would have to be in the charset of the searched column. In cases where collation matters, the search value in the constraint would need a CAST().

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

That's the key thing. The situation was made more difficult than "perfect world" by the fact that the INTL changes were not fully implemented in v.2.0, requiring possible further intervention (beyond that needed for old-->2.0) to use a non-ascii database that worked OK with 2.0.

>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.

Not "inconsistent" from the Firebird p.o.v., though. You (and the tools) must distinguish between metadata and data, specifically in DDL that provides text constants in expressions defining constraints, computed columns, domains, etc., and also user-defined triggers and stored procedures that have been migrated without recompiling.

./heLen