Skip to Content.
Sympa Menu

freetds - RE: FreeTDS with MS SQL Server 2000

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "G . Sumner Hayes" <SumnerH AT fool.com>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: RE: FreeTDS with MS SQL Server 2000
  • Date: Fri, 23 Feb 2001 11:04:57 -0500


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




Archive powered by MHonArc 2.6.24.

Top of Page