freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: Brian Bruns <camber AT umcc.ais.org>
- To: TDS Development Group <freetds AT franklin.oit.unc.edu>
- Subject: Re: M$ SQL 7, again ;-)
- Date: Fri, 10 Sep 1999 21:51:11 -0400 (EDT)
On Fri, 10 Sep 1999, Paul Schaap wrote:
> On 09/10/99, "Brian Bruns <camber AT umcc.ais.org>" wrote:
> > So, it appears that microsoft has broken big endian support for the above
> > types. Good news it can be fixed. Try and do that with closed source
> > libraries!
>
> Not only do the libraries give me a fast fix they give me the hardware
> independance I desire also :-)
>
Well, if we can get the big endian issues sorted out that is.
I commited a fix to CVS which hopefully works. It requires a make
clean/make of anything using the libraries (header file changes).
I have not tested it on big endian machines yet, so I'm not sure it works,
but I'll be doing that shortly (possibly tonight yet). I'm really, really,
really hoping that microsoft either leaves this broken until 7.1 or
somehow differentiates the service pack in which they fix it otherwise
things get interesting in how to detect the problem.
> Thanks Brian and Michael for looking into this ! I also presume your
> silence on the 'hungry' php issue indicates I should approach a php forum,
> as I thought was the likely outcome, or you would like a more thorough
> analysis from me ?
>
Yeah, a little more info would be nice. A small php script showing the
problem with necessary table definition would be even better. ;)
> > > On 09/10/99, "Michael Peppler <mpeppler AT peppler.org>" wrote:
> > > > Paul Schaap writes:
> > > > > Hi,
> > > > >
> > > > > I have a fairly recent CVS freetds which has the following two
> > > > issues :-
> > > > >
> > > > > 1) With both php and sqsh dates come through incorrectly, i.e.
> > > > > 1> SELECT ID,DateAdded FROM Customer WHERE ID > 10001434
> > > > > 2> \go
> > > > > ID DateAdded
> > > > > -------- -------------------
> > > > > 10001435 Aug 11 1903 06:51AM
> > > > > 10001436 Aug 30 1903 06:51AM
> > > > > 10001437 Nov 25 1903 06:51AM
> > > > >
> > > > > (3 rows affected)
> > > > > 1> SELECT ID,CONVERT(CHAR(20),DateAdded) FROM Customer WHERE ID >
> > > > 10001434
> > > > > 2> \go
> > > > > ID
> > > > > -------- --------------------
> > > > > 10001435 Sep 10 1999 9:32PM
> > > > > 10001436 Sep 10 1999 9:51PM
> > > > > 10001437 Sep 10 1999 11:18PM
> > > > >
> > > > > (3 rows affected)
> > > > > I resolve this by doing a CONVERT right now ! Any ideas how it
> > > > could be
> > > > > fixed ?
> > > >
> > > > Looks like the first and second word of the DATETIME value are swapped
> > > > on MSSQL7... Remember that a datetime is a struct with two 32bit int
> > > > values, one for days since Jan 1 1900, and one for 300th of seconds
> > > > since midnight.
> > > >
> > >
> > > Interesting. I can see I need to test this on big endian. The 32bit
> > > values
> > > themselves seem to be byte-ordered correctly. However if it treats
> > > dates as
> > > a single 64bit value on the server side it would indeed show this
> > > behaviour. I'll verify against Solaris/Sybase tonight when I get home,
> > > but
> > > my feeling is it's wrong there as well. Simple patch if thats the case.
> > >
> > > Brian
> > >
> > >
>
> Thanks Again
> Paul Schaap
>
-
Re: M$ SQL 7, again ;-),
Michael Peppler, 09/10/1999
- <Possible follow-up(s)>
- Re: M$ SQL 7, again ;-), Brian Bruns, 09/10/1999
- Re: M$ SQL 7, again ;-), Brian Bruns, 09/10/1999
- Re: M$ SQL 7, again ;-), Paul Schaap, 09/10/1999
- Re: M$ SQL 7, again ;-), Brian Bruns, 09/10/1999
- Re: M$ SQL 7, again ;-), Bill Tutt, 09/11/1999
- Re: M$ SQL 7, again ;-), Bill Tutt, 09/11/1999
- M$ SQL 7, again ;-), Paul Schaap, 01/29/2024
Archive powered by MHonArc 2.6.24.