FreeTDS Development Group

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

Hi Bill, 

Thanks for your essay.  It and Bob's data made things pretty clear.  Some
grumbles and observations follow.  

On Thu, 21 Nov 2002 08:10:54 -0000, "Thompson, Bill D (London)"
<ThompBil AT exchange.uk.ml.com> wrote:
> 
> Output parameters from stored procedures are still supported. So:
> 
> declare @b int
> exec t0022 @b = @b output
> 
> is STILL a valid piece of TSQL

... but to use it, all db-lib programs will now have to be rewritten....

> What has changed is that the TDS 7 protocol will no longer return the
> contents of @b in a "parameter result" message, after a piece of SQL
> like this is submitted to the server. The reasoning behind this is as
> follows:
> 
> In TDS 4.2 , there was no "low-level" or "direct" way of submitting a
> stored procedure call to the server. The only way of doing that was to
> submit a SQL statement like the one above. In order to get the ouptut
> parameter back to the client, the TDS 4.2 protocol supported a
> "parameter result" message when stored procedure calls were submitted in
> this way. If you look at it though, this is a bit of a cludge. In this
> piece of SQL, we have declared a variable, and then called a stored
> procedure to populate it via an output parameter. Thats fine, and the
> server will do exactly what it's asked to do. But there's nothing in
> that SQL which really says that the client is interested in the contents
> of the variable after the stored procedure call. So why return it ?

I always thought the word "output" was a clue.  :)

> In TDS 7.0, there now IS a direct way of submitting a stored procedure
> call to the server, passing input parameters and retrieving output
> parameters. So the former method is now redundant.

Well, it's no accident the address is "One Microsoft Way" is it?

OK, I'm done being snide.  What to do?  Here's how I see it.  

The TDS_RETURNVALUE (0xac) token was used only by db-lib programs and has
been considered "obsolete" by Sybase for five years.  Microsoft dropped
support for it midstream, as part of a "service pack" (seems more like an
unservice pack to me).  

Commentary.  In so doing, Microsoft subtly broke some db-lib programs. 
Ordinary mortals, people with lives, don't know about TDS_RETURNVALUE. 
They use binaries, and those binaries will now stop working quite right. 
Most of them will never find out what changed, and they're certainly never
going to start a "save the token" campaign.  They'll just find out that
something that used to work doesn't anymore, and after they call tech
support (or not) they'll decide to upgrade.  That benefits Microsoft
(fewer db-lib apps, less server-side support) and third part vendors.  You
won't find any better example of the values and methods of proprietary
software.  

FreeTDS, being free software and thus very explicit about its
capabilities, discovered this breakage as part of its own testing.  Chalk
one up for the good guys.  Yay, Nick.  

We can't emulate the old behavior, can't emit the token ourselves, without
parsing the SQL.  

What to do?  

For unittest purposes, I think t0022.c should assume TDS 7+ will not
support TDS_RETURNVALUE and should anticipate that dbnumrets() will return
0.  I suggest that if it does, it should call dbsetversion(DBVERSION_42)
and try again.  

If we don't have one already, we should have an rpc version of t0022.c. 
Well, maybe we should have more than a stub implementation in rpc.c,
first. ;)  Seems to me that has been made more urgent.  Am I correct that
libtds is rpc-ready, and that all we need to do is the db-lib
implementation?  

And, of course, we should document it.  

Other suggestions?

--jkl