FreeTDS Development Group

[Brian Bruns <camber AT umcc.ais.org>]

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
> >