FreeTDS Development Group

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

Kevin,

I had a patch for this (I know I sent it to gregg, I think I applied it to
CVS).  Some of the changes to read.c made it drop a byte on a packet
boundary. I'll repost the patch after I look through my sent mail.

Brian


On Wed, 27 Jan 1999, Kevin wrote:

> Gregg Jensen wrote:
> > Sam, weren't you doing some real stuff with this library on Solaris 
> > (Sparc?)?  I
> > was wondering if you had experienced any problems with the new stuff?  I
> > have compiled the latest into sqsh-1.4 and it either doesn't like 
> > time/date or int4
> > columns, because sqsh core dumps while trying to print out these two 
> > columns side
> > by side. (ie, I am not sure if its a problem with time/date of int4 or 
> > something else).
> > It almost seems like it doesn't parse the token properly.  But, the same 
> > code on
> > Linux (Intel) parses just fine.  Have you (or anyone else) experienced 
> > anything
> > similar?
>       Sam and I are working on some real stuff with just the TDS library on
> Solaris. Basically, we've had to set up a server to send a few simple
> queries from our Solaris box to an NT box running MSSQL 6.5 through a
> CGI interface. Basically, all we're using is libtds v0.40 (with Sam's
> midifications to read.c) and sqsh-1.4 since I still am having a few
> problems actually compiling the version I checked out from CVS (local
> configuration problems, not Makefile :) ).
>       There have, however, been some strange results popping up every once
> and a while with time/date values. Basically, as I understand it, the
> server sends the time/date value like this:
>       bytes 0-3: Days since Jan 1, 1900.
>       bytes 4-7: 300th's of a second since midnight
>       byte  8  : Unknown ( value end marker? )
> 
>       Occasionally, when we pull 300+ row returns on a query, we've had an
> off by one error somewhere, and have lost the first byte of the
> date/time value. After doing some hex dumps of the packets, it didn't
> look like it was missing bytes across packet boundries, or, in fact,
> anywhere else I could find.
>       What I did find, and I'm perfectly willing to admit is an anomoly of
> some sort, is that the last byte of the date/time value was getting lost
> somewhere. Again, that could just be me...
> 
> -- Kevin
> -----------------------------------------------------------------------
> Kevin M. Lyons         Phone: (402)-471-7870     Email: kevin AT nol.org
>       No matter what happens, somebody will find a way to take it way too
> seriously - Dave Barry
> -----------------------------------------------------------------------
> 
> ---
> You are currently subscribed to freetds as: camber AT ais.org
> To unsubscribe, forward this message to $subst('Email.Unsub')
> 
>