FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

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