FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

I've added a config option 'emulate little endian' (boolean option,
accepts yes/on, on/off, true/false or 1/0) for the freetds.conf
file.  Using TDS 7 will automatically cause this to be set.

Theoretically this will allow big endian clients to appear to the server
as little endian, thus putting an end to the perpetual stream of microsoft
bugs affecting big end clients.

It's not complete yet, but Paul if you can test TDS 7 on Linux PPC, int
and smallint types *should* return correctly now. Let me know.

Brian

On Thu, 12 Jul 2001, Mark J. Lilback wrote:

> At 7:13 AM -0400 7/12/01, Brian Bruns wrote:
> >Mark,
> >
> >Is this limited to an MS-SQL server? It seems to be the date problem all
> >over again.  I'm thinking that we will support a 'emulate little endian'
> >mode for big end machines that will be used with TDS 7 and for big end
> >machines connecting to broken versions of SQL Server.  Which version is
> >the server that exhibits this behaviour?
> 
> This is with SQL Server 7, pre SP3. I've conditionalized my code so 
> that once a connection is open, I query the server to get what 
> version it is("master.dbo.xp_msver ProductVersion"). If it is less 
> than 961, I set dbproc->tds_socket->broken_dates to 1, otherwise i 
> set it to 0. (Since SP3 fixes the bigendian date problem.)
> 
> I'm compiling freetds into a plugin for MacSQL Monitor, a generic 
> database tool. Because I need a lot of specific data not provided by 
> any of the apis, the plugin is hard-coded for SQL Server only. That's 
> all I've tested against, too.
> 
> For this patch, it might be possible to detect if it is necessary. 
> It's been a while since I was debugging this, but I believe you'll 
> get a completely impossible message code if the data isn't swapped 
> properly (I think it is negative, but I'd have to check). The test 
> could be if bigendian and if (rc < 0).
> 
> 
>