Subject | Re: [firebird-support] Re: Non - printable characters in Stored Procedures |
---|---|
Author | Tim Ledgerwood |
Post date | 2003-11-05T09:45:46Z |
>OK - that all sounds very logical.
>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
So now how do I convert a db with a default 'NONE' charset to something I
can use? How do I choose what I should be using?
Regards
Tim
[Non-text portions of this message have been removed]