FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Steven J. Backus [mailto:backus AT math.utah.edu]
> Sent: July 31, 2003 6:28 PM
> 
> > A little before the I5 conversion is the dage conversion.  
> Your table has
> > that as datatype float, 8 bytes, and you're binding it to a 
> C float, 4
> > bytes.  Does anything change if you redefine the age column 
> as datatype
> > "real" instead?  
> 
> I changed float to real in the table definition.  I changed float
> to DBREAL in the program.  Now the output looks correct:
> 
> id          did         dmonth      dday        dyear       
> dage orderinlist i1   i2   i3   i4   i5   family 
> ----------- ----------- ----------- ----------- ----------- 
> ---- ----------- ---- ---- ---- ---- ---- ------ 
> 176936      300004      2           5           1904        
> 79   1           NULL NULL NULL NULL I64  Y      
> 
> But i5 still is messed up:
> 
> (gdb) print i5
> $1 = "\00064\000\001"

If the output is OK, perhaps the debugger is confused.  

What is sizeof(float) in your compiler?  If 8, we know the problem.  If 4,
we don't.  

I reviewed the floatn/float/real conversions and they look both simple and
right.  I don't know if we've prevented the corruption or merely gone around
it.  

I think to completely debug this requires more than we can do through email.
I can't reproduce it, and you're not familiar enough with the code to hunt
down where it's going wrong.  If you're determined to keep looking, you'll
have to become better versed in the logic, and try to narrow things down a
little more actively.  I can offer some suggestions:

1.  Reduce the query.  The log you sent includes stuff not in your original
query:

> 16:25:19.777231 tds_process_default_tokens() marker is ae(CONTROL)
...
> 16:25:19.777429 tds_process_default_tokens() marker is a9(ORDERBY)

followed by a second row.  

2.  Remove columns from the query until you find the one that seems to
trigger the problem.  The difficulty is, we have a symptom but no known
cause.  Something wrote "TY" after I64; rearranging things such that "TY"
gets written elsewhere (but still in error) only makes it harder to find.  

3.  Add printf() to the called functions to print out all the inputs, so we
can see where they go wrong.  

4.  Repeatedly print the contents of your bound variables and the contents
of the TDSSOCKET structure, particularly the column information and current
row information (data).  Somewhere in there is where the problem lies.  I
suspect something is altering the row data after it's read causing
tds_convert() to think the i5 column is wider than it is.  A nicely
formatted dump of TDSCOLINFO would be a big help here.  

The theory of operation is that the metadata are read from the wire and
stored in the socket structure.  Then the row is read and parsed according
to the metadata.  Once established, the metadata don't change for the
duration of the result set.  Once read from the wire, the row data are never
modified.  But sometimes theory and practice are different, in practice.  

If you do all that, and look at the results for both cases (when age is 8
and 4 bytes), perhaps something will stick out.  At the very least, we'll
have better information.  

I hope this is useful to you.  I'm trying to give you the tools you need to
discover the source of the error.  It would be great if what comes out of
the process is a patch fixing a bug we wouldn't have otherwise known about.


Regards, 

--jkl
-----------------------------------------
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.