FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

Ok, let's see what we can do.  Can you be a bit more precise as to how it
screws up unicode?  The short term fix to get tds 7.0 working was to strip
unicode of the upper byte (which works for an iso_1 character set). Is
this what you are seeing?

If you can give a better description of what you're trying to do (PHP,
perl, C, ?) perhaps it is time to implement some locale support.

Brian

On Thu, 22 Feb 2001, Spyros Ioakim wrote:

> Ok guys... I have already brought up the same problem.
> tds 4.2 isn't capable of fetching large fields (>255) but is capable
> of working with unicode..
> tds 7.0 can fetch large fields (>255) but screws up unicode.
> 
> So what do you do when you need both?
> 
> casting a text field as memo seems to work but again no unicode.
> 
> unfortunately i'm only an end user and can't help you fix the bug.
> but you have all my beta testing support if you need it :-))
> 
> I'm trying to access an sql 7.0 server via a linux box with php for
> the record...
> 
> Spyros
> 
> ----- Original Message -----
> From: "Cecil Stump" <cecil AT chs.picker.com>
> To: "TDS Development Group" <freetds AT franklin.oit.unc.edu>
> Sent: Thursday, February 22, 2001 7:00 PM
> Subject: [freetds] RE: FreeTDS with MS SQL Server 2000
> 
> 
> > Hi Brian,
> >
> > I must retract my earlier statment about unicode being a problem with
> > freetds 7.0. My original unicode problem was noted with freetds-7.0 on
> > release 0.50. Since I did not need unicode, and since I thought I recalled
> > reading that unicode was still a problem with 7.0, I did not pursue the
> > issue after upgrading to release 0.51.
> >
> > Revisiting the unicode problem today, with release 0.51, I have determined
> > that NVARCHAR[] (unicode) fields appear to be working properly.
> >
> > However, I still get a core dump when accessing the Northwind sample
> > database (included with MS SQL 2000) Employee table with
> >
> >  SELECT * FROM Employees
> >
> > BUT ... closer investigation shows that is is not the NVARCHAR datatype,
> but
> > the IMAGE[] datatype ( aka TEXT[] ) which is causing my segmentation fault
> > core dumps.
> >
> > I noted in your response today to Myers Carpenter's post concerning TEXT[]
> > fields that you are already aware of this issue.
> >
> > If I can be of assistance in gathering more explicit information or
> testing
> > hypothesis for you, please drop me a line.
> >
> > Regards,
> > Cecil Stump
> >
> >
> > > -----Original Message-----
> > > From: bounce-freetds-127248 AT franklin.oit.unc.edu
> > > [mailto:bounce-freetds-127248 AT franklin.oit.unc.edu]On Behalf Of Brian
> > > Bruns
> > > Sent: Thursday, February 22, 2001 9:16 AM
> > > To: TDS Development Group
> > > Subject: [freetds] RE: FreeTDS with MS SQL Server 2000
> > >
> > > On Wed, 21 Feb 2001, Cecil Stump wrote:
> > >
> > > There would have been the upgrade to 0.51, ctlib handles null terms two
> > > different ways, and we were only handling one case.  Also, if you want
> to
> > > expand on the unicode problem, maybe we can get it fixed.  (I don't have
> > > access to SQL Server 2000, so it'll be a lot of blind guesses on my
> part).
> > >
> > > Brian
> >
> > >
> >
> >
> > ---
> > You are currently subscribed to freetds as: [sioakim AT ace-hellas.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')
>