FreeTDS Development Group

[James K. Lowden <jklowden AT speakeasy.org>]

On Sun, 1 Sep 2002 18:01:02 -0400 (EDT), "Brian Bruns" <camber AT ais.org>
wrote:

> I think perhaps the best solution would be to support multi-byte char 
> sets, period.  Be it big5 or ucs-2 or whatever.  This is particularly
> nice for our asian users as their non-unicode aware applications are 
> multi-byte.  UCS-2 could be converted to big5, and then bound to the 
> application in that format.  The biggest thing here would simply be to 
> remove all reference to strlen() as it is applied to items within the
> row buffer, and some fixups to conversion code (int is an int but the
> string representation in multibyte is tricky), most likely we convert to
> ascii (as all numbers, and decimal point are ascii) using the standard
> unix functions and convert from there using iconv.  

Well, that would be interesting.  A FreeTDS that doesn't care about nulls
in its string buffers and doesn't ever make any assumptions about
character width, of course, could pass UCS-2 straight through.  That would
be better than dual conversion, for sure.  

I was working from the assumption (more than the knowledge) that that
would be hard to accomplish.  I thought passing UCS-2 would be about as
much fun as passing a kidney stone.  

> Don't get me started on datetimes.

OK. ;)

> What's needed? unicode columns in SQL Server and a terminal that support
> 
> utf-8 with sqsh.  

Yup.  AIUI, UTF-8 has been hacked into the Linux console, but that's about
it.  There's no free xterm that understands it.  You'd have to pipe the
output to a browswer or something.  

+++

Made some progress on the UG.  Am a little concerned about cancel
processing wrt the release.  What do you think?

Regards, 

--jkl