That sounds like the most reasonable & usable way to do it.

Dave

> -----Original Message-----
> From: Patrick J. P. Griffin
> [mailto:patrickjpgriffin@...]
> Sent: Monday, January 08, 2001 12:10 AM
> To: IB-Architect@egroups.com
> Subject: RE: [IB-Architect] [ Bug #127473 ] isql always
> ignores charset
> NONE in metadata extraction
>
>
> Dave,
>
> Thanks. The patch I was about to commit (your message
> literally arrived
> just moments before I was ready to type the command)
> implements most of what
> you suggest.
>
> When using the ISQL Copy command (available only in
> development builds) my
> patch does exactly what you suggest by explicitly stating
> each character
> set.
>
> When using just the ISQL extract command (or ISQL's Show
> command) the patch
> will show the character set NONE definition when ever the
> database default
> character set has been set to something else.
>
> Where I differ is that my patch currently will suppress the
> printing of the
> character set definition when that character set is the
> same as the database
> default character set.
>
>
> Opinions?
>
> ...pat
>
>
> -----Original Message-----
> From: David Schnepper
> [mailto:dschnepper@...]
> Sent: Sunday, January 07, 2001 10:04 PM
> To: Ann W. Harrison; IB-Architect@egroups.com
> Subject: RE: [IB-Architect] [ Bug #127473 ] isql
> always ignores charset
> NONE in metadata extraction
>
>
> 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]
>
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
>
>

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