FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

Hi,

The unicode -> ascii conversion that is present in FreeTDS is *very*
simple and is not internationalized at all.  (Note: I am a english
speaking american with all the bad conotations that brings with it).  So,
like many things in FreeTDS, I have never added it because 1) I haven't
needed it personally and 2) Nobody needing it has dedicated enough time to
solving it.

I'd be happy to put in a solution for mapping unicode, but I don't have
the foggiest notion what is required or how to do it.  Is there a standard
for converting unicode to national character sets? Is free software (read:
something compatible with LGPL) available that will do this?  If not, we
have to roll our own.  And I have no experience with multibyte character
sets (big5 etc..) so how to deal with those is a mystery to me as well.

For the curious, all we would need is a bit of book-keeping information in
the TDSSOCKET structure and some configuration info to go along with it,
and then modify the tds7_unicode2ascii() and
tds7_ascii2unicode() functions to do the actual work.  Not really too
complicated...

Brian

On Thu, 7 Jun 2001, Niky Riga wrote:

> The Data in the database is in Greek and is in Unicode. When I used TDS 7.0 
> all greek
> caracters where "corrupted". As I have already read in another article 
> "..FreeTDS 7.0
> presents a charset encoding problem, when using MS SQL server (and I 
> believe other sql
> servers too) from PHP.
> 
> All non ascii national characters (which codes a greater than 127) become 
> corrupt when
> updating the SQL server. Retrieving properly stored national characters 
> from SQL
> server does not work well too.
> The problem is, that all the non ascii characters are converted to Unicode 
> by TDS."
> 
> And the only solution proposed was to use TDS 4.2.
> 
> Another thing if instead of ntext I use text, then I can retrieve the data 
> but the
> last character is lost.
> 
> "Lowden, James K" wrote:
> 
> > By using TDS 4.2, you're identifying yourself to SQL Server 2000 as an old
> > client, which is why it calls you a "DB-Library" client.  In truth, 
> > whether
> > you use Db-lib or ODBC, you're a TDS client by the time you show up at the
> > server's door, but you'd never know that from their stupid message.
> >
> > What the message is telling you:  Don't send Unicode while you're relying 
> > on
> > TDS 4.2.  If you want Unicode, you want TDS 7.0.
> >
> > Can you get what you need done with Ascii, or do you need Unicode?  If you
> > need Unicode, what exactly is the "problem with ASCII characters with 
> > code >
> > 127"?
> >
> > --jkl
> 
> > -----Original Message-----
> > From: nriga AT noc.ntua.gr [mailto:nriga AT noc.ntua.gr]
> > Sent: June 7, 2001 8:45 AM
> >
> > I try to access a Database in SQL server 2000 with PHP via FreeTDS.
> > I use C-libraries. When I try to retrieve a ntext field I get the
> > following warning
> >
> > <<Warning: Sybase: Server message: Unicode data in a Unicode-only 
> > collation
> > or ntext data cannot be sent to clients using DB-Library (such as ISQL) or
> > ODBC version 3.7 or earlier. (severity 16, procedure N/A) >>
> >
> > I use TDS 4.2. I know that it may work fine with TDS 7.0 but with TDS 7.0
> > I have problem with ASCII characters with code > 127.
> >
> > ---
> > You are currently subscribed to freetds as: [nriga AT noc.ntua.gr]
> > To unsubscribe, forward this message to $subst('Email.Unsub')
> 
> 
> ---
> You are currently subscribed to freetds as: [camber AT ais.org]
> To unsubscribe, forward this message to $subst('Email.Unsub')
>