--- In firebird-support@yahoogroups.com, Tim Ledgerwood <tim@s...> >
Yeah, I would also like to know. I have never used anything else other
than

> NONE, and it hasn't ever caused me problems that I am aware of.

Storing character with character set NONE tells the database
that it should not attach any semantics to the bytes stored.
They are just bytes.

Bytes in the range 0..127 are weakly equivalent to their
corresponding ASCII codepoints and bytes in the range 128..255
are totally without semantics.

So, if you or your customer find at some sunny day in the
future a byte 224 in some character field, everybody can
start guessing which character it is.

Also charset none makes the migration to a sane (defined) use
of charsets difficult.

Connecting with a defined charset to a charset none database
gives transliteration errors for the app=>db direction.

But when connecting with charset none, and you try to use a
defined charset for just one column, you get transliteration
errors for the db=>app direction.

The only reason for the existance of charset none, is the
absence of useful defaults. CHAR should default to system
character set and locale (or selected ISO-8859-x and locale
at installation time for advanced users) and NCHAR should be
Unicode of some flavour.

Regards,
Peter Jscobi