FreeTDS Development Group

["G . Sumner Hayes" <SumnerH AT fool.com>]

This is all tdsver=7.0 with freetds-0.51.

Just some data points for you all.  I'm successfully getting
back Unicode NTEXT fields from SQL 2000, though there isn't
a symbolic constant defined for them (should be a "#define
XSYBNTEXT 99" in tds.h).  They come back with the textsize in
res_info->columns[0]->column_textsize and that many UTF16 encoded
bytes in res_info->columns[0]->textvalue--at least that's what it
looks like to me.  I'm writing Python wrappers, and passing those
values to PyUnicode_DecodeUTF16 appears to work fine, though I've
only tested on latin-1 characters.

I'm also pulling out large SYBTEXT fields somewhat successfully,
though the mechanism for doing it is a nasty hack.  I do the
following to get the full text field into c_string:

size_t c_strsize=1;
char *c_string=malloc(1);
c_string[0]='\0'

for(i=0; i<res_info->num_cols; i++) {
  if(res_info->columns[i]->column_textvalue) {
    c_strsize+=strlen((char *)res_info->columns[i]->column_textvalue);
    c_string=realloc(c_string, c_strsize);
    strcat(c_string, (char *)res_info->columns[i]->column_textvalue);
  }
}

I have no idea why this works, but it seems to pull >128K
fields without problems.  It obviously could be more efficient
(replace strcat with a memcpy of strlen bytes, grow the string
exponentially) but I'm only concerned with correctness at the
moment.

SYBDATETIME, SYBDATETIMN, SYBVARCHAR, SYBCHAR, and SYBINT[14N]
appear to work as well.  Haven't tested anything else, I'm
knocking them off only as needed.

  Sumner

Brian Bruns <camber AT ais.org> wrote:
> 
> 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')
> > 
> 
> 
> 
> ---
> You are currently subscribed to freetds as: [SumnerH AT fool.com]
> To unsubscribe, forward this message to $subst('Email.Unsub')

-- 
rage, rage against the dying of the light