Skip to Content.
Sympa Menu

freetds - Re: [freetds] FreeTDS problems with converting SQL BigInt

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: freetds AT lists.ibiblio.org
  • Cc: Feroze Daud <khichdo AT yahoo.com>, FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] FreeTDS problems with converting SQL BigInt
  • Date: Sun, 22 Sep 2013 11:28:10 -0400

On Fri, 20 Sep 2013 16:05:32 -0700 (PDT)
Feroze Daud <khichdo AT yahoo.com> wrote:

> 1) I changed my program to read the value as a double, then cast it
> to bigint. In this case it works.

Well done!

> 2) I ran tcpdump and captured a network trace. I looked at it in
> wireshark, and noticed that the server is sending the correct value...
>
> 0040  c8 31 04 00 10 00 00 49  01 00 81 01 00 00 00
> 21   .1.....I .......! 0050  00 6c 11 13 00 0d 4d 00  61 00 78 00 49
> 00 50 00   .l....M. a.x.I.P. 0060  50 00 51 00 75 00 65 00  75 00 65
> 00 49 00 44 00   P.Q.u.e. u.e.I.D. 0070  d1 05 01 4c 47 07 00 ff  01
> 00 c1 00 01 00 00 00   ...LG... ........
>
> At offset 76, you can see the value 0x000747c which is exactly the
> value the sproc is sending for MaxIPPQueueID ( decimal 477004 ).

Yes.

> I just started reading the MS-TDS spec, and am not an expert in it,
> so I dont know what datatype the server is advertizing.

Short of a bug in the server, we can be sure the server the metadata
are correct. If you run the query using bsqldb or bsqlodbc, the -v
option prints the metadata.

> But I am wondering why the library is corrupting this value.

I look forward to seeing the results of unittest/genparams on you
system.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page