Skip to Content.
Sympa Menu

freetds - Re: [freetds] truncated data from query

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] truncated data from query
  • Date: Thu, 5 Oct 2006 08:54:40 +0200

> robert lazarski wrote:
> > > Ach, sorry, I'm wasting your time. Let's just see the
> TDSDUMP output.
> > >
> >
> > Since this file is big, I put it here for those that want
> to look at it:
> >
> > http://www.braziloutsource.com/random/freetds.log
> ...
> > The dt.sql content I ran is:
> >
> > EXEC sp_generate_inserts [FUNDASSET],@owner =
> [dbo],@ommit_images = 1,
> > @disable_constraints = 1
> >
> > That produced about 20 lines truncated like:
> >
> > | INSERT [dbo].[FUNDASSET]
> >
> ([fundAssetID],[created],[modified],[createdUserID],[modifiedU
> serID],[c
> >
> urrentShares],[washRuleDate],[maxPositionSize],[maxPositionRea
> son],[ann
> >
> ualizeReturn],[expectedReturnCalculation],[assetID],[fundID],[
> statusID]
> > ,[categoryID])VALUES(1,NULL,NULL,NULL,NULL,1250000,'Jul
> > 5 200|
>
> OK. Here's a piece of the log.
>
...
>
> That's a complete insert statement:
>
> "INSERT [dbo].[FUNDASSET]
> ([fundAssetID],[created],[modified],[createdUserID],[modifiedU
> serID],[cur
> rentShares],[washRuleDate],[maxPositionSize],[maxPositionReaso
> n],[annuali
> zeReturn],[expectedReturnCalculation],[assetID],[fundID],[stat
> usID],[cate
> goryID])VALUES(1,NULL,NULL,NULL,NULL,1250000,'Jul 5 2006
> 12:00:00:000AM',NULL,'','','',1,1,1,4)"
>
> So we know it's received correctly from the server (and, btw,
> that you're
> using TDS 8.0). There are no errors in the log, not even
> anything about
> insufficient buffer size from the library to the application.
>
> I would be astonished if a column -- any column, but especially an
> ordinary varchar -- would be truncated in the FreeTDS ODBC
> driver. I'd be
> more likely to wonder about isql, to tell you the truth.
>

I can confirm is a isql problem.

> So could we take a step back for a minute? You're not trying
> to implement
> anything in terms of unixODBC's isql; that's just a testing
> tool, and just
> maybe it has this limitation. What's the target environment?
> PHP? Can
> you use samples/odbctest.php with your query, and see if the
> same problem
> manifests itself? Something along those lines?
>
> The only direct way to test this is to write and debug a little test
> application in C that executes your query and prints the
> result. It would
> be nice to have our own general-purpose isql-like tool for
> ODBC; it would
> help in flushing out bugs (or proving they don't exists).
> But no one's
> found the time to do that yet.
>

Or you can enable odbc trace.

freddy77





Archive powered by MHonArc 2.6.24.

Top of Page