Without fulling understanding the in's and out's of the issues here,
I'll go ahead and interject a few inputs from the author's standpoint:

-- It is not possible to specify a column to have the "database
default character set".
-- If you do NOT specify an explicit character set on the column
definition, it is
equivilant to saying "character set <database default character
set>".

These are from the SQL standards, and I took pains to follow the spec
in this (and many other) regards.

As painful as it seems, the correct way to export a schema is to
always explicitly declare the column character set for each column
definition. That way the schema will be exactly reproduced when
executed.

Now, SQL'isms aside, it is incredibly useful to not give the explicit
character set for each column, both for readability and for moving a
schema to a new character set.

And, another off hand remark:
- Even though I defined character set NONE, ASCII, and OCTETS, the
subtle differences between them always drove me batty. I would do
away with NONE if I could. It's original purpose was to give users of
3.2 and below a way to migrate to 3.3 (&4.0 and above).

Dave

> -----Original Message-----
> From: Ann W. Harrison [mailto:harrison@...]
> Sent: Sunday, January 07, 2001 9:23 AM
> To: IB-Architect@egroups.com
> Cc: Dave Schnepper
> Subject: Re: [IB-Architect] [ Bug #127473 ] isql always
> ignores charset
> NONE in metadata extraction
>
>
> At 01:35 AM 1/6/2001 -0500, Patrick J. P. Griffin wrote:
> >I've been meditating on [ Bug #127473 ] isql always
> ignores charset NONE in
> >metadata extraction and I've got a question.
>
> Patrick,
>
> I've just looked at the collation_id and character_set_id
> fields in rdb$fields for a simple database. There seems to
> be neither rhyme nor reason to the use of null and zero in
> those fields. Normally that means there's something major
> I haven't understood, so I'm looking for a correction here.
>
>
> If we use 0:0 to mean an explicit NONE, and null:null to mean
> unspecified, then here is the assignment order I would use:
>
> if a charset, including null, is specified for a field,
> that field retains that char set.
>
> else if a charset is set for the database
> fields from that table retain that charset
>
> else the field adopts the charset of its new database.
>
> Patrick's puzzle:
>
> >Database A has no default character set.
> >
> >Database A has the table T1 with field F1 with no
> character set specified.
> >
> >Database A has the table T2 with field F2 with character
> set NONE explicitly
> >specified.
> >
> >
> >Database B uses the default character set WIN1251.
> >
> >
> >Using ISQL to copy the table structure for T1 into Database B, what
> >character set should be used for the field F1?
>
> WIN1251, by default.
>
> >Using ISQL to copy the table structure for T2 into Database B, what
> >character set should be used for the field F2?
>
> None, explicitly.
>
> >And, for extra credit, how about:
> >
> >Database C uses the default character set WIN1251
> >
> >Database C has the table T3 with field F3 with no
> character set specified
> >(will be defined with WIN1251)
> >
> >Database C has the table T4 with field F4 with character
> set NONE explicitly
> >specified.
> >
> >
> >Database D uses the default character set CYRL.
> >
> >
> >Using ISQL to copy the table structure for T3 into Database D, what
> >character set should be used for the field F3?
>
> Win1251.
>
> >Using ISQL to copy the table structure for T4 into Database D, what
> >character set should be used for the field F4?
>
> None, explicitly
>
>
> >Should fields with no explicit character set in one
> database assume the
> >default character set of the target database?
>
> Not always. If the source database has a default character
> set, then
> those fields should carry that character set.
>
> >Should fields explicitly or implicitly using the default
> character set of
> >one database assume the default character set of the
> target database?
>
> Fields that explicitly use a character set (including NONE) in
> one database should use the same character set in other databases.
>
> Fields that implicitly use a character set in one database should
> continue to use that character set if and only if source database
> has an explicit character set.
>
> Fields defined with no explicit character set should have a null
> collation id and a null
>
>
>
> Regards,
>
> Ann
> www.ibphoenix.com
> We have answers.
>
>
>

[Non-text portions of this message have been removed]