Skip to Content.
Sympa Menu

freetds - RE: freetds and SQL server 2000

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: RE: freetds and SQL server 2000
  • Date: Thu, 7 Jun 2001 17:24:46 -0400 (EDT)


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





Archive powered by MHonArc 2.6.24.

Top of Page