FreeTDS Development Group

[Bob Kline <bkline AT rksystems.com>]

Until this happens (adding Unicode support to freetds), best you can do
in the freetds world is store your mixed-language data as Unicode
encoded in UTF-8.

On Tue, 11 Apr 2000, Brian Bruns wrote:

> If you absolutely have to have unicode then you need TDS 7.0. period. TDS
> 4.2 doesn't support it at all.  Even the freetds C libs basically just strip
> the unicode strings down to latin 1, although that could be changed with a
> little effort, but the basic problem is dblib doesn't support unicode at the
> API level.
> 
> I'm looking at the JDBC sources right now, (first time I've done so,
> actually) and it is definately 4.2 only. Patching in a TDS 7 login seems to
> be pretty simple, ditto for the TDS 7 result packet, but string handling is
> another story.  I've seen several places where the size of a string is
> assumed to be in bytes (which is the same thing the C libs used to do).
> Craig seems to have placed all the protocol related stuff in one class (good
> move), so it could be much worse.
> 
> So, if someone wants to tackle this, I can tell you what needs to be done,
> but I'm not really a Java guy.
> 
> Brian
> 
> On Tue, 11 Apr 2000, Stefanos Karasavvidis wrote:
> 
> > thanks for the info, but your suggestion to use simple text attributes is 
> > not
> > possible. When I use simpole text fields I can't write the text I want... 
> > period.
> > 
> > My application includes text from 6 different languages.... the five of 
> > them are all
> > Latin-1 codepage but the last is greek which is another codepage. The 
> > text is mixed up
> > so I need Unicode attributes.
> > 
> > The fact that I get strings correctly back from SQL Server when the text 
> > contains
> > characters from different code pages makes me believe that the jdbc 
> > driver does not
> > handle cha and nchar the same way. I'm sure that they make some kind of 
> > String
> > construction according to the text type. There is no other explanation, 
> > and there is
> > not "automagic" conversions :-))))
> > 
> > Greetings
> > 
> > Stefanos
> > 
> > Stefan Bodewig wrote:
> > 
> > > >>>>> "SK" == Stefanos Karasavvidis <stefos AT multimedia-sa.gr> writes:
> > >
> > >  SK> Stefan Bodewig wrote:
> > >
> > >  SK> If I (or anyone) use simple varchar/char/text columns, SQL Server
> > >  SK> uses 8bit per character.
> > >
> > > Believe me Stefanos, I know what you are talking about.
> > >
> > > And as to "in Latin character world (english)" I'm german and do
> > > heavily rely on freetds_jdbc to retrieve my umlauts correctly. Then
> > > again those are in latin-1 so I'm probably part of the latin character
> > > world.
> > >
> > > Actually the String returned to you by ResultSet.getString() is the
> > > same for nchar and for char columns as the JDBC driver doesn't even
> > > know it's an nchar column.
> > >
> > > Taking this last thing into account (freetds_jdbc doesn't know about
> > > nchar) and the fact that it works for you, somebody is making the
> > > right conversion for you - SQL Server or Java. This is why I suggested
> > > to try the ordinary TEXT type, maybe it will also work automagically.
> > >
> > >  SK> I'm happy that I have this minimal but still uncomplete
> > >  SK> functionality from the freeTDS project
> > >
> > > As I've said before my suggestions are in no way meant as the final
> > > solution to this problem. The final solution should be a JDBC driver
> > > that supports TDS 7.0.
> > >
> > > Given the fact that the C libs already support it this may well
> > > happen - but just don't hold your breath.
> > >
> > > Stefan
> > >
> 
> 
> ---
> You are currently subscribed to freetds as: bkline AT rksystems.com
> To unsubscribe, forward this message to $subst('Email.Unsub')
> 

-- 
Bob Kline
mailto:bkline AT rksystems.com
http://www.rksystems.com