FreeTDS Development Group

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

Dan Wierenga wrote:
> I've attached the TDSDUMP logs for stored procs that have datetime, int,
> float, and varchar output params, as well as my mini-suite of tests.  I
> ran them against both Sql Server 2000 and SQL Server 2005, with the 0.64
> codebase and the 0.82 codebase, for TDS protocol versions 4.2, 7.0, 8.0,
> and 9.0.
> 
> Since there's a ton of stuff in my attachments I'll give a quick
> summary:
> - output params are broken for TDS 7.0 and 8.0 in both 0.64 and 0.82 
> - output params work for TDS 4.2 and 9.0 for the 0.64 codebase
> - output params work for TDS 4.2 for the 0.82 codebase
> - TDS 9.0 throw connect errors for the 0.82 codebase (ugh.. see the
> do_tests.errors file)

Dan, 

This just excellent, thanks!  I haven't had a chance to look at it all in
detail yet, but wanted to point out the TDS 9.0 stuff is probably
something trivial, although I don't know where the error is. 

oak[0.82_results]$ grep '(TDS version' *.log \
| sed 's/net.c:210:Connecting to 192.168.94.... port ....//'
sql_2000.tds_4.2.log: (TDS version 4.2)
sql_2000.tds_7.0.log: (TDS version 7.0)
sql_2000.tds_8.0.log: (TDS version 8.0)
sql_2000.tds_9.0.log: (TDS version 5.0)
sql_2005.tds_4.2.log: (TDS version 4.2)
sql_2005.tds_7.0.log: (TDS version 7.0)
sql_2005.tds_8.0.log: (TDS version 8.0)
sql_2005.tds_9.0.log: (TDS version 5.0)

As you can see, the "TDS 9.0" logs tried to connect as TDS version 5.0. 
That's because with 0.82, TDS 9.0 isn't enabled by default:

$ sed -ne /ENABLE/,/endif/p src/tds/config.c 
#ifdef ENABLE_DEVELOPING
        } else if (!strcmp(tdsver, "90") || !strcmp(tdsver, "9.0")) {
                connection->major_version = 9;
                connection->minor_version = 0;
                return;
#endif

with the result that the library ignored "9.0" when it found that version
in your freetds.conf (or TDSVER), and reverted to the compiled-in default,
5.0.  

So, no big deal.  I don't want to call these things 8.0 and 9.0 anyway. 
Microsoft labels them 7.1 and 7.2 in their recently released
documentation, and we should follow them.  Those values are more in
keeping with the degree of change, too.  

As for why output parameters don't work, I don't know yet, and my analysis
will have to wait until after I get some sleep.  The answer is roughly
here:

net.c:779:Sending packet
0000 03 01 00 3f 00 00 01 00-0a 00 73 00 70 00 5f 00 |...?.... ..s.p._.|
0010 65 00 78 00 65 00 63 00-75 00 74 00 65 00 00 00 |e.x.e.c. u.t.e...|
0020 00 00 26 04 04 01 00 00-00 00 00 af 0f 00 0f 00 |..&..... ........|
0030 49 20 61 6d 20 74 68 65-20 57 61 6c 72 75 73    |I am the  Walrus|
...
net.c:671:Received packet
0000 ff 11 00 c1 00 01 00 00-00 ff 01 00 e0 00 01 00 |........ ........|
0010 00 00 79 00 00 00 00 fe-00 00 e0 00 01 00 00 00 |..y..... ........|

In the 4.2 log, the server responds with a row, which Perl duly finds and
provides to the caller.  In this 7.0, there's no row.  We'll have to
compare what Perl is sending to what's done in db-lib and ct-lib for
output parameters.  

Once again, Dan, excellent work, thanks.  We've really got something to
chew on now!  

Regards, 

--jkl