FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

On Fri, 10 Nov 2000, Mark Schaal wrote:

> > 
> > On Fri, 10 Nov 2000, Mark Schaal wrote:
> > > What I understand "connection level" to mean, and I could be wrong,
> > > is that the user could specify per connection "I want you to mimic
> > > little/big-endian".  However, the only need I am aware of is to 
> > > mimic little-endian on big-endian machine for TDS7.0 connections,
> > > which we can auto-detect and set properly without user intervention.
> > 
> > Not entirely true.  Some (all?) versions of SQL Server 7 have broken dates
> > and money.  They send in little endian regardless of what was requested.
> > If Microsoft fixes this in a service pack then, when talking to 7.0 SP1
> > freetds needs to correct but for SP3 (or other mythical bug fix version)
> > we must not fix it.  There is no way to tell server version really, other
> > than a compile time option.  So the best way to handle this may be to flat
> > emulate little endian with TDS 4.2. 
> > 
> > So, a TDS 4.2 connection to SQL Server may need to talk little endian and
> > a TDS 4.2 connection to Sybase may need to be native (big endian) format.
> > 
> > This is what I meant by allowing per connection endianess may be a good
> > idea.  Microsoft doesn't really appear to give a hoot about big endian
> > clients, and it's not likely to get any better.  It's has no use in TDS
> > 5.0, I'll agree.
> > 
> 
> I didn't realize that SQLServer7 was broken under TDS4.2.  My point (and
> I do have one :) still is that optimally we don't want to put the burden
> on the end user of figuring out that they need to flip a magic switch 
> to get their connection to work.  So here's another suggestion - could
> we use the login ack packet to grok the server type?  The below comes
> from MSSQL 7.0 SP2, and the 0700 in the magic bytes is certainly
> suggestive.  If we could get MSSQL login acks from a few other sources
> and compare we could see if there's a pattern.
>
 
We can tell the major/minor version information but nothing gives the
service pack in use (short of issuing a select @@version and parsing the
results, ugh). Right now the code applys the fix if it finds a SQL 7
Server of any sort (see tds->broken_dates in token.c...), but IMO that
is fragile and likely to break if MS decides to fix the bug in a future
SP (it has a bug number, but remained unfixed last time I checked).  

So, what to do? I don't like making the user fix it either, and what is
there *does* work for now, but it is very hackish. I just hate being at
the mercy of MS's latest service pack, and if/when they fix it the user
*will* have to specified whether they have broken date handling or not,
and then what if you have some servers on 7.0SP2 and some on 7.0SP3?
Compile two copies of the code and link against the right one? Or set a
config somewhere...

Brian