Hello johnson_dave2003,

Friday, March 4, 2005, 3:28:05 PM, you wrote:

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

Here's what is directly from SQL-2003 standard:

<data type> ::=
<predefined type>
| <row type>
| <path-resolved user-defined type name>
| <reference type>
| <collection type>

<predefined type> ::=
<character string type> [ CHARACTER SET <character set specification> ]
[ <collate clause> ]
| <national character string type> [ <collate clause> ]
| <binary large object string type>
| <numeric type>
| <boolean type>
| <datetime type>
| <interval type>

And, <data type> is the data type that you specify for a column.
Also, Firebird supports feature F461 "Named character sets", which
means that character sets are supported using the character set DDL
and DML syntax. One thing that is mentioned in the SQL-2003 in
regards to the character sets, is that it is more or less
implementation defined as to how it works internally.

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

I have no problem with that. What I was referring to, was making the
case about using more than one collation simultaneously in a WHERE
clause and/or ORDER BY clause.

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

You'll still have to specify which character set will be used to
"represent" the field data, even if the data is saved internally with
the same dataset.


--
Best regards,
Daniel Rail
Senior Software Developer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)