FreeTDS Development Group

[Brian Bruns <camber AT umcc.ais.org>]

Ok, I think I've got this one. 

PHP relies on some interesting undocumented behaviour on the part of the
Sybase libraries. OpenClient apparently memset()'s strings to ' ' (space)
before converting dates to char.  So if you have say:

Sep 13, 1999 18:00:00

It would be followed by a null character and then the remainder of the
string is spaces. 

Now when dbconvert() is passed a -1 for the destination length,
which means the buffer is large enough to handle the string, and the
string is to be null term'd, dblib still memset()'s it to spaces.  The
question is: where does it get this size? I set it to 30, because PHP has
the dbdatlen() + 20 (which is 28). But it seems pretty dangerous to me to
be initializing memory beyond the end of the string!

Anyway, after PHP gets the string back he starts at the res_length (28)
and works his way backward to find a non space character and this is the
length of the string.  Thus when freetds returned 'Sep 13, 1999 18:00:00'
followed by the null character, followed by undefined values, the
res_length remained 28 and the null and garbage characters were included
in the output, which kills netscape and probably didn't look too pretty
under IE either. So, freetds has been 'fixed' to replicate the OpenClient
behaviour even though I don't agree with it.

By the way for the curious, a better way of doing this is to use the
return from dbconvert() to get the size of the resulting string.  I am
going to patch PHP to do this correctly. 

Anyway, once again get the latest CVS and give it a try.

Cheers,

Brian

On Mon, 13 Sep 1999, Brian Bruns wrote:

> 
> Well, it seems to be the same issue in that you have a null in the output
> stream. However, dbdatlen() shouldn't come into play here, so it's a
> different cause (but same result). I'll look into later day (getting ready
> to drop my son off at school now, so I only have a minute).
> 
> I've got a few ideas, I'll post back to the list if any of them pan
out.
> 
> Brian
> 
> On Mon, 13 Sep 1999, Paul Schaap wrote:
> 
> > Brian,
> > 
> > > Ok, looking at things, I may not need to be so drastic. PHP does 
> > > something
> > > like this:
> > > 
> > > res_length = dbdatlen(dbproc, offset);
> > > dbconvert(NULL,coltype(offset),dbdata(sybase_ptr->link,offset), 
> > >           res_length,SYBCHAR,res_buf,-1);
> > > 
> > > So it should indeed null terminate them (the -1 means to null term the
> > > result), however dbdatlen() returns an incorrect value. I fixed that and
> > > also fixed it for the NULL case as well. I'm going to try all the test
> > > cases tommorow on a real dblib machine and then I think I should be able
> > > to fix the other cases. But try the latest CVS and let me know.
> > > 
> > > Brian
> > > 
> > 
> > For the VARCHARS this is now OK. Back onto the DATETIME issue, certain in
> > the knowledge that the library IS dynamically compiled, I have done a 
> > little more testing to reveal that DATETIME data is also hungry ! Could 
> > you
> > safely apply this patch to the DATETIME data types ?
> > 
> > As I mentioned before using sqsh worked perfectly but php did not. 
> > Therefore I tried a full recompile apache and php against the working 
> > freetds from scratch to no avail. I therefore think the next question is 
> > if
> > datetimes are being treated differently, or, if the hungry issue is the 
> > cause, or, if we should bother wasting any more time on it ?
> > 
> > >From php ...
> > ID       Raw                 Converted
> > 10001486 Feb 25 2003 03:50AM Sep 13 1999 4:15PM
> > 10001485 Jan 29 2003 03:50AM Sep 13 1999 3:48PM
> > 10001484 Jan 10 2003 03:50AM Sep 13 1999 3:29PM
> > 10001483 Nov 24 2002 03:50AM Sep 13 1999 2:42PM
> > 10001480 Jun 03 2002 03:50AM Sep 13 1999 11:48AM
> > 
> > >From sqsh ...
> >  ID        DateAdded
> >  -------- ------------------- --------------------
> >  10001486 Sep 13 1999 04:15PM Sep 13 1999  4:15PM
> >  10001485 Sep 13 1999 03:48PM Sep 13 1999  3:48PM
> >  10001484 Sep 13 1999 03:29PM Sep 13 1999  3:29PM
> >  10001483 Sep 13 1999 02:42PM Sep 13 1999  2:42PM
> >  10001480 Sep 13 1999 11:48AM Sep 13 1999 11:48AM
> > 
> > I'm also concerned any change to fix the php link may affect sqsh :-(
> > 
> 
>