FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

As a follow on to this.  I'm intending on making broken data handling
configurable per server along with the other config changes (I'm
overhauling the whole configuration thing).  I'll post when I check it in.

Brian

On Wed, 14 Feb 2001, David Ramsey wrote:

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