Offer Encoding As Latin1 Option
Offer Encoding As Latin1 Option

This allows you to run:

   >> ODBC-SET-CHARACTER-ENCODING 'LATIN1

That instructs the ODBC extension to store CHAR() and VARCHAR() fields
as Latin1-encoded data.

SQL introduced "NCHAR" for "Native Characters", which typically are
2-bytes-per-character instead of just one.  As time has gone on, that's
no longer enough...and the UTF-8 encoding is the most pervasive way of
storing strings on the web.  But it uses a varying number of bytes per
character, which runs counter to SQL's desire for fixed-size-records.

There is no clear endgame in the SQL world for what is going to be done
about this.  So many text strings (that might have emoji/etc.) get
stored as BLOB, which limits their searchability from within the SQL
language itself.

Since Ren-C makes the long bet on UTF-8, it will default to storing and
fetching UTF-8 from CHAR-based fields.  But some systems (e.g. Excel)
will use Latin1 when writing into CHAR() fields via SQL interfaces.  So
if you are to say:

 odbc-execute c "insert into [test$] (id, test) values ('101', 'ľšč');"

Then that won't store the field as valid UTF-8.  As a workaround, this
lets you globally set the encoding/decoding of CHAR fields.

giuliolunati/ren-c,hostilefork/rebol,rgchris/ren-c,rgchris/ren-c,rgchris/ren-c,hostilefork/rebol,hostilefork/rebol,hostilefork/rebol,giuliolunati/ren-c,giuliolunati/ren-c,giuliolunati/ren-c,giuliolunati/ren-c,hostilefork/rebol,rgchris/ren-c,rgchris/ren-c,hostilefork/rebol