--- In Firebird-Architect@yahoogroups.com, Daniel Rail <daniel@a...>
wrote:

> Hello johnson_dave2003,
>
> Thursday, March 3, 2005, 11:10:26 PM, you wrote:
>
> > Let me flip the question around - does SQL2003 support a keyword

in

> > DML for specifying character set?
>
> Yes, it does. And, you can specify a different character set for

each

> column in a table, as it is know possible in Firebird.

Firebird/Interbase SQL supports the CHARSET keyword, but SQL2003 does
not have this as a standard feature.

>
>
> > But you can't change collations in mid stream.
> > That is to say, within a single query you can't sort by one

column in

> > EN_US and the neighboring column in FR_FR, or sort different

parts of

> > a complex query in different collations.
>
> This might have to be possible, especially if the table contains 2
> fields of different characters sets and both of those character sets
> don't support the same collations. And, that you are specifying

those

> 2 fields in the order by clause.
>
> 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.

The entire intent of this approach is to remove the concept
of "character sets" as a plural from the server engine entirely. If
this concept is ultimately accepted, characters would be stored as
UTF-8 (period), and the retrieval process (whether on the client or
the server) converts UTF-8 to whatever is needed "on demand".

>
> One thing that would be nice to have removed is having to specify a
> character set on connection, especially if it's possible to have
> multiple character sets defined within the database(i.e.: fields,
> domains, etc...).

The entire intent of this approach is to remove the concept
of "character sets" as a plural from the server engine, and turn them
over to one end of the session connection.

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