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: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] truncated data from query
  • Date: Wed, 4 Oct 2006 21:24:24 -0400

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],[modifiedUserID],[c
> urrentShares],[washRuleDate],[maxPositionSize],[maxPositionReason],[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.

06e0 1f 09 04 d0 00 34 00 d1-54 01 49 4e 53 45 52 54 |.....4.. T.INSERT|
06f0 20 5b 64 62 6f 5d 2e 5b-46 55 4e 44 41 53 53 45 | [dbo].[ FUNDASSE|
0700 54 5d 20 28 5b 66 75 6e-64 41 73 73 65 74 49 44 |T] ([fun dAssetID|
0710 5d 2c 5b 63 72 65 61 74-65 64 5d 2c 5b 6d 6f 64 |],[creat ed],[mod|
0720 69 66 69 65 64 5d 2c 5b-63 72 65 61 74 65 64 55 |ified],[ createdU|
0730 73 65 72 49 44 5d 2c 5b-6d 6f 64 69 66 69 65 64 |serID],[ modified|
0740 55 73 65 72 49 44 5d 2c-5b 63 75 72 72 65 6e 74 |UserID], [current|
0750 53 68 61 72 65 73 5d 2c-5b 77 61 73 68 52 75 6c |Shares], [washRul|
0760 65 44 61 74 65 5d 2c 5b-6d 61 78 50 6f 73 69 74 |eDate],[ maxPosit|
0770 69 6f 6e 53 69 7a 65 5d-2c 5b 6d 61 78 50 6f 73 |ionSize] ,[maxPos|
0780 69 74 69 6f 6e 52 65 61-73 6f 6e 5d 2c 5b 61 6e |itionRea son],[an|
0790 6e 75 61 6c 69 7a 65 52-65 74 75 72 6e 5d 2c 5b |nualizeR eturn],[|
07a0 65 78 70 65 63 74 65 64-52 65 74 75 72 6e 43 61 |expected ReturnCa|
07b0 6c 63 75 6c 61 74 69 6f-6e 5d 2c 5b 61 73 73 65 |lculatio n],[asse|
07c0 74 49 44 5d 2c 5b 66 75-6e 64 49 44 5d 2c 5b 73 |tID],[fu ndID],[s|
07d0 74 61 74 75 73 49 44 5d-2c 5b 63 61 74 65 67 6f |tatusID] ,[catego|
07e0 72 79 49 44 5d 29 56 41-4c 55 45 53 28 31 2c 4e |ryID])VA LUES(1,N|
07f0 55 4c 4c 2c 4e 55 4c 4c-2c 4e 55 4c 4c 2c 4e 55 |ULL,NULL ,NULL,NU|
0800 4c 4c 2c 31 32 35 30 30-30 30 2c 27 4a 75 6c 20 |LL,12500 00,'Jul |
0810 20 35 20 32 30 30 36 20-31 32 3a 30 30 3a 30 30 | 5 2006 12:00:00|
0820 3a 30 30 30 41 4d 27 2c-4e 55 4c 4c 2c 27 27 2c |:000AM', NULL,'',|
0830 27 27 2c 27 27 2c 31 2c-31 2c 31 2c 34 29 d1 53 |'','',1, 1,1,4).S|
0840 01 49 4e 53 45 52 54 20-5b 64 62 6f 5d 2e 5b 46 |.INSERT [dbo].[F|

That's a complete insert statement:

"INSERT [dbo].[FUNDASSET]
([fundAssetID],[created],[modified],[createdUserID],[modifiedUserID],[cur
rentShares],[washRuleDate],[maxPositionSize],[maxPositionReason],[annuali
zeReturn],[expectedReturnCalculation],[assetID],[fundID],[statusID],[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.

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.

Don't worry: you won't have to abandon this toolchain. It's just a small
matter of figuring out what's wrong and fixing it. It might not even
affect your target.

Regards,

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page