Skip to Content.
Sympa Menu

freetds - Re: Release 0.41 ...on Solaris(Sparc)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Kevin <kevin AT nol.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Release 0.41 ...on Solaris(Sparc)
  • Date: Wed, 27 Jan 1999 21:17:55 +0000


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
-----------------------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page