Skip to Content.
Sympa Menu

freetds - Re: Big Endian Patches

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: David Ramsey <dramsey AT neosoft.com>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Big Endian Patches
  • Date: Wed, 14 Feb 2001 09:35:00 -0600


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
>
> ---
> You are currently subscribed to freetds as: [dramsey AT neosoft.com]
> To unsubscribe, forward this message to $subst('Email.Unsub')

--
David Ramsey -- dramsey AT neosoft.com

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




Archive powered by MHonArc 2.6.24.

Top of Page