Skip to Content.
Sympa Menu

freetds - RE: Strange error in tsql

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
  • Subject: RE: Strange error in tsql
  • Date: Thu, 7 Nov 2002 17:12:32 -0500


> From: Frediano Ziglio [mailto:freddyz77 AT tin.it]
> Sent: November 7, 2002 4:35 PM
> >
> > But 5.0 sends ee, ae, d1, 1, 0?
> > Received packet @ 2002-11-07 15:43:34.383225
> > 0000 ee 0d 00 01 00 00 30 0a 00 00 00 6c 21 4d 12 00
>
> Row, numeric of 33 (yes, 33!) bytes. So we must change
> numeric limit...
> (in tds.h is defined as 17 bytes...)

I'm trying to interpret that packet:

ee TDS_ROWFMT
0d 00 13 byte packet
01 00 1 column
00 Name length = 0
30 status nullable, updatable (!)
0a 00 00 00 user type numeric
6c nullable numeric
21 33 bytes wide
4d precision 64+13 = 77
12 scale 18
00 no locale

Is that right?

Wow. That's one big number, 10 ^ (77 - 18), like a gazillion or something.

--jkl



> > 0010 ae 01 00 00 d1 21 01 00 00 00 00 00 00 00 00 00
>
> Yes, is a 33 bytes
>
> from token.c
>
> /* server is going to crash freetds ??*/
> if (colsize > sizeof(num->array))
> return TDS_FAIL;
> tds_get_n(tds,num->array,colsize);
>
> So, we have two problem:
> - numeric should support 256 bit number, not only 128
> - we do not check result of tds_get_data...
>
> freddy77
>


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.






Archive powered by MHonArc 2.6.24.

Top of Page