FreeTDS Development Group

[David Ramsey <dramsey AT neosoft.com>]

As a followup, my fix (which works for me here for both SQSH and
DBD::Sybase) was to just remove the version check in tds_process_row()
and set tds->broken_dates = 1 when WORDS_BIGENDIAN is defined at compile
time.

I do not know if this is the best solution but it works for what I need
right now. I am pulling data from a MS SQL Server 6.5 database that is
embedded in a commercial product and posting that data to an enterprise
Oracle 8i database where we can post-process the data. And this solution
lets me write a perl script that can be cron'd to run automatically.

The entire experience though leaves me wondering if there are some
fundamental issues regarding the endian-ness of the client versus the
server regardless of version of TDS protocol involved. If I had more
time and opportunity to look at the issue I would but unfortunately, I
have other tasks assigned to me.

Unless someone posts a better solution, I plan to leave mine in place in
my TDS libraries. I will continue to monitor the list in case a better
solution is found.

And once again, thank you all for a great library.

David Ramsey wrote:
> 
> Thanks for the tip, Michael. I looked at the TDSDUMP logs and noticed
> what you were saying so looking at tds_convert_datetime() and
> tds_convert_datetime4(), I saw that the problem is the SOURCE data and
> the byte swapping for big endian was only occurring when the destination
> was also a SYBDATETIME[4] data type.
> 
> To resolve that, I moved the byte swap code to the front of the function
> so that it would take effect regardless of what the target data type was
> since the problem is in the source data type. I then added a tdsdump_log
> call to tds_convert_datetime() to get a closer look at what was
> happening.
> 
> After rebuilding and watching the log dumps further, I was shocked to
> see SQSH calling the convert routines repeatedly on the same item before
> it is processed. Apparently this is acceptable behavior in the Sybase
> libs (I'm an Oracle guy so forgive me here) so this indicates to me that
> the word swapping should not be done in convert.c but earlier when the
> datastream is initially read from the socket from the server. What I saw
> happening was multiple calls to tds_convert_datetime that ended up
> undoing what was being done and now, despite having made the fix to the
> source data type global, I find myself with the fix being undone in SQSH
> simply because an odd (as opposed to even) number of calls to
> tds_convert_datetime() has been made.
> 
> I really believe that the data needs to be word swapped when it is
> received from the server. However, I am very new to the Free TDS
> libraries and would appreciate any pointers as to where the best place
> to make that conversion might be.
> 
> Thanks to all!
> 
> Michael Peppler wrote:
> >
> > David Ramsey writes:
> >  > Ok, now I am seeing some weird behavior. With the patch in place, I can
> >  > use SQSH 1.7 and access the SQL Server database and get proper date
> >  > outputs. But using the same libraries to link DBD::Sybase against and
> >  > running the same query, I am getting the dates in gibberish now. I am
> >  > quite certain this is a byte ordering issue but is there anywhere else
> >  > to look inside Free TDS or do I need to dig into the DBD::Sybase code?
> >
> > DBD::Sybase just does a ct_bind() with a CS_CHAR_TYPE target, whereas
> > sqsh calls ct_bind() to the native datatype, and then calls
> > cs_convert() to display the data item.
> >
> > This might point at some weirdness in either the implementation of
> > cs_convert() or ct_bind() in the FreeTDS libs.
> >
> > Michael
> > --
> > Michael Peppler - Data Migrations Inc. - mpeppler AT peppler.org
> > http://www.mbay.net/~mpeppler - mpeppler AT mbay.net
> > International Sybase User Group - http://www.isug.com
> > Sybase on Linux mailing list: ase-linux-list AT isug.com
> >

-- 
David Ramsey -- dramsey AT neosoft.com

-- There is an old Vulcan proverb: only Nixon could go to China.