FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

One obvious way to develop and test UTF-8 et. al. conversions is with bcp.
In combination with iconv(1), we'd have a simple way to test test
conversions, without the need for font support or foreign language skills.
For instance, I have a file 256 bytes long produced by this program:

#include <stdio.h>
int main()
{
        int i;
        for (i=0; i < 0x100; i++) {
                putchar(i);
        }
        return 0;
}

As you can see, it produces all the valid values in any ISO-8859-X character
set.  You'll be pleased to learn that as of today, freebcp can transmit this
file back and forth to the database.  'Twas not always thus.  

It's a simple matter to convert the file to UTF-8 with iconv, and also to
send it to the database with freebcp.  If we could also extract it from the
database specifying UTF-8 as the client character set, we could use diff(1)
-- possibly along with hexdump(1) -- to compare our conversion to iconv's.  

Thus far, however, freebcp doesn't know from character sets.  Like any other
db-lib client, it will cause libtds to use libiconv if so indicated in
freetds.conf for that server.  But that's not very flexible for a data
migration tool.  

Looking over Sybase's bcp reference manual, I see their utility has many
character set related options, some of which we don't need because we have
libiconv and freetds.conf: -a, -J, -q.  Of these, I think we need only -q.
Does anyone see a need for the others?  

The domain of the -q parameter is naturally enough the domain of
master..syscharsets character set names.  I think for freebcp -q should take
a libiconv name.  I'm also not sure it's all that desirable to use "-q".
I'm thinking '-c' could optionally take a charset name instead.  Of people
interested in freebcp, I'd like to know if you think emulating Sybase's
choices is important.  

Please tell me if I've overlooked something.  

--jkl



The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.