FreeTDS Development Group

["Castellano, Nicholas" <Nicholas_Castellano AT acml.com>]

This issue isn't dead...I've been working on it silently for a few days now.
So far I have narrowed it down considerably, and it seems that Microsoft
broke this between SQL 7.0 SP2 and SP3.  I hope to be able to determine this
week whether it was an intentional behavior change or if it is a bug, and
precisely when the behavior changed (I will be testing each hotfix between
SP2 and SP3 to determine the latter).

Here is my testing matrix so far, more details later when I narrow it down
further.  So far, my working assumption is that this is a bug in MS SQL
Server, and has nothing to do with FreeTDS.

Cheers,
--nick

-----Original Message-----
From: bounce-freetds-145195 AT franklin.oit.unc.edu
[mailto:bounce-freetds-145195 AT franklin.oit.unc.edu] 
Sent: Monday, October 14, 2002 10:47 AM
To: TDS Development Group
Subject: [freetds] Re: Output parameters (src/dblib/unittests/t0022.c)


Hi all,

I'm just picking up on this old issue, as I've stumbled across it whilst
doing some re-testing on the latest code (in particular
dblib/unittests/t0022).

I have found the same thing that others discovered, namely that in TDS7/8
the "0xac" parameter return stream is missing when the stored procedure in
t0022 is executed. It is definitely present in TDS4.2, and also in TDS 5.0
with Sybase. Hmmmm.

My betting is that this information will only be returned if we implement
the streams that underly dbrpcinit, dbrpcparam, dbrpcsend/dbrpcexec . That's
only a hunch however. There's something in the SQL server
(dbrpcinit) help which suggests a difference between using these calls and
not, to whit:

"Using DB-Library functions instead of an EXECUTE statement accommodates
return parameters for stored procedures more quickly. With a remote stored
procedure, the return parameters are always available to the application by
calling dbretdata. (Note, however, that a return parameter must be specified
as such when it is first added to the stored procedure through
dbrpcparam.)
If a stored procedure is called with an EXECUTE statement, the return
parameter values are available only if the command batch containing the
EXECUTE statement uses local variables, rather than constants, as the return
parameters. This involves additional parsing each time the command batch is
executed."

I know that this doesn't explicitly say you HAVE to use dbrpcinit etc. to
see the return parameters, but that's where my money is anyway.

Is anyone working on the dbrpc* functions ? 

Bill

---
You are currently subscribed to freetds as: [Nicholas_Castellano AT acml.com]
To unsubscribe, forward this message to
$subst('Email.Unsub')


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 for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.

Attachment: t0022.csv
Description: Binary data