Daniel Rail wrote:

>Although to some it might not make much sense to use 2 different
>character sets within the same table, Firebird does give that ability
>and removing it is not wise. As an example, some might use the OCTET
>character set to store binary data within a field, but the other
>fields are ISO8859-1.
>
>

There are scenarios where it makes perfectly good sense. Single table
may have two fields containing the English and French translations of a
phrase or a document. That said, there is no reason that the English
and French versions need be stored in different character sets to
preserve this capability. How the data is stored is an internal
mechanism, invisible to clients.

>
>
>>>I'm happy quite happy with a shorter and simpler list:
>>>
>>> 1. Collation specified in query DML
>>> 2. Collation declared as default in the session.
>>>
>>>
>
>Jim, don't forget the field's default collation, before the session's.
>
>
>
>

I didn't forget it -- I left it out on purpose. In my mind, collation
is a property of data manipulation operation, not the data itself. It
may be useful as a default for indexes containing that field, but I
don't think it should override the default collation specified by a
client. I'm willing to concede that a declaration of case insensitivity
expressed as a collating sequence doesn't work well with this model.
I'm not happy with that, and I'm going to have to think about it some more.


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376