Re: seems dblib can get TDS protocol wrong in unusual case

"James K. Lowden" <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <[email protected]>
Frediano Ziglio wrote:
> After some tests and after checking ms dblib bahavior I think this is
> a false problem. Like ODBC in this case dblib generate a sort of empty
> recordset with no rows. After dbsqlok set dbresults_state to
> _DB_RES_SUCCEED dbresults returns SUCCEED without any token processing
> but it also set dbresults_state to _DB_RES_NEXT_RESULT so on next
> dbresults call token processing take place again without discupting
> anything...

Hi Freddy, 

Nice work, as usual.  

Could you run an SQL batch through bsqldb -v and point to the resultset
the OP says is missing?  

Perhaps Ted Hayes will be willing to provide us with a query that works
with his change but not without.  

I would really like to understand exactly what is wrong with this, if
anything.  If we can't get a definitive test, though, I'm prepared to
believe it was just a misunderstanding.  

For reference, the original message was posted on 11 November 2008 and
includes the below packet.  The assertion was that the last TDS packet was
mistakenly discarded.  

Regards, 

--jkl

net.c:671:Received packet
0000 ff 00 51 00 02 00 00 00-01 ff 00 41 00 02 00 00 |..Q..... ...A....|
0010 00 00 ff 00 51 00 02 00-00 00 01 ff 00 51 00 02 |....Q... .....Q..|
0020 00 00 00 01 ff 00 41 00-02 00 00 00 00 ff 00 51 |......A. .......Q|
0030 00 02 00 00 00 01 ff 00-51 00 02 00 00 00 01 ff |........ Q.......|
0040 00 41 00 02 00 00 00 00-ff 00 51 00 02 00 00 00 |.A...... ..Q.....|
0050 01 ff 00 41 00 02 00 00-00 00 ff 00 51 00 02 00 |...A.... ....Q...|
0060 00 00 01 ff 00 51 00 02-00 00 00 01 ff 00 41 00 |.....Q.. ......A.|
0070 02 00 00 00 00 ff 00 51-00 02 00 00 00 01 ff 00 |.......Q ........|
0080 51 00 02 00 00 00 01 ff-00 41 00 02 00 00 00 00 |Q....... .A......|
0090 ff 00 41 00 02 00 00 00-00 ff 00 51 00 02 00 00 |..A..... ...Q....|
00a0 00 01 ff 00 51 00 02 00-00 00 01 ff 00 51 00 02 |....Q... .....Q..|
00b0 00 00 00 01 ff 00 41 00-02 00 00 00 00 ff 00 51 |......A. .......Q|
00c0 00 02 00 00 00 01 ff 00-41 00 02 00 00 00 00 ff |........ A.......|
00d0 00 51 00 02 00 00 00 01-ff 00 41 00 02 00 00 00 |.Q...... ..A.....|
00e0 01 ff 00 51 00 02 00 00-00 01 fe 00 09 00 02 00 |...Q.... ........|
00f0 00 00 01 ff 00 41 00 02-00 00 00 00 ff 00 41 00 |.....A.. ......A.|
0100 02 00 00 00 00 ff 00 51-00 02 00 00 00 01 ff 00 |.......Q ........|
0110 51 00 02 00 00 00 01 ff-00 41 00 02 00 00 00 00 |Q....... .A......|
0120 ff 00 41 00 02 00 00 00-00 ff 00 41 00 02 00 00 |..A..... ...A....|
0130 00 00 ff 00 41 00 02 00-00 00 00 ff 00 51 00 02 |....A... .....Q..|
0140 00 00 00 01 ff 00 51 00-02 00 00 00 01 ff 00 41 |......Q. .......A|
0150 00 02 00 00 00 00 ff 00-41 00 02 00 00 00 00 ff |........ A.......|
0160 00 41 00 02 00 00 00 00-ff 00 41 00 02 00 00 00 |.A...... ..A.....|
0170 00 7c 36 f1 19 65 00 00-00 00 a0 00 0b 0a 76 65 |.|6..e.. ......ve|
0180 72 73 69 6f 6e 53 74 72-a1 00 06 00 00 00 02 27 |rsionStr .......'|
0190 3d ae 00 01 00 d1 11 32-30 30 36 31 31 31 33 5f |=......2 0061113_|
01a0 31 36 3a 33 37 3a 31 31-ff 00 51 00 02 00 00 00 |16:37:11 ..Q.....|
01b0 01 ff 00 51 00 02 00 00-00 01 79 00 00 00 00 fe |...Q.... ..y.....|
01c0 00 08 00 02 00 00 00 01-                        |........|
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.