Subject Re: UTF-8 (various)
Author johnson_dave2003
--- In, Daniel Rail <daniel@a...>
> Hello johnson_dave2003,
> Thursday, March 3, 2005, 11:10:26 PM, you wrote:
> > Let me flip the question around - does SQL2003 support a keyword
> > DML for specifying character set?
> Yes, it does. And, you can specify a different character set for
> 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
> 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
> and removing it is not wise. As an example, some might use the
> 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