[freetds] state of dbrpcsend()

Thompson, Bill D (London) bill_d_thompson at ml.com
Wed Jun 9 10:16:19 EDT 2004

Hey Liam,

I've just taken a *quick* look at your data. It seems to me, you've got the
idea slightly wrong. 

You call dbrpcparam() three times, suggesting you expect the stored
procedure to have three parameters, the last of which (@rc) is an output
Yet your stored procedure only has two parameters (@lowest, @highest) - both
input parameters.

You *may* be confusing a stored procedure return status (which would take
the value zero from your "RETURN 0" statement in the sp), with an output
parameter, which is something completely different.

to make the sp match your C code you'd have to make it like this:

ALTER PROC sp_freetds_test (@lowest INT, @highest INT, @rc INT OUTPUT)
	@rc = 0

      RETURN 0

to make the C code match your sp you'd have to omit the third call to
dbrpcparam() and capture the return status with the appropriate calls to
dbresults, dbhasretstat and dbretstatus 

The SQL server BOL entry for dbrpcinit() is pretty good on how to use the
rpc functions in dblib...


> -----Original Message-----
> From:	liam at inodes.org [SMTP:liam at inodes.org]
> Sent:	09 June 2004 03:59
> To:	freetds at lists.ibiblio.org
> Subject:	[freetds] state of dbrpcsend()
> Hi,
> I've been reading through the archive and in particular the threads
> between Sasha Polyanovskyi and James Lowden. Is someone able to 
> clearly describe what state dbrpcsend() is currently in? Is it working,
> broken, somewhere in between?
> I've been trying (in vain) to get both the stable (0.62.1) and CVS 
> versions (0.63.dev.20040608) of the db-lib implementation of FreeTDS 
> working with stored procedures. The unit tests work, but my stored 
> procedures do not. I can however use regular SQL statements without 
> any issue. I can call these stored procedures with 'tsql' without
> any issue either.
> My code is as follows:
> int test_function(int lowest, int highest) {
> 	int retval;
> 	dbinit();
> 	dblogin();
> 	...
> 	dbrpcinit(proc, "sp_freetds_test", 0)
> 	dbrpcparam(proc, "@lowest", 0, SYBINT4, -1, -1, 
> 	           (BYTE *) &lowest);
> 	dbrpcparam(proc, "@highest", 0, SYBINT4, -1, -1, 
> 	           (BYTE *) &highest);
> 	dbrpcparam(proc, "@rc", DBRPCRETURN, SYBINT4, -1, -1,
> 	           (BYTE *) &retval);
> 	dbrpcsend(proc);
> 	...
> }
> The function fails at dbrpcsend(). The stored procedure looks as
> follows:
> ALTER PROC sp_freetds_test (@lowest INT, @highest INT)
> AS
> 	...
> GO
> Doing a packet trace with a sniffer reveals that it appears that no
> packets other than login are ever sent on the wire.
> Unfortunately, it appears $TDSDUMP is broken in the CVS version but
> in the stable version, I get:
> 12:55:00.656769 tds_process_end() state set to TDS_IDLE
> 12:55:00.656817 leaving tds_process_login_tokens() returning 1
> 12:55:00.685218 dbrpcinit() added rpcname "sp_freetds_test"
> 12:55:00.685356 dbrpcparam() added parameter "@lowest"
> 12:55:00.685405 dbrpcparam() added parameter "@highest"
> 12:55:00.685451 dbrpcparam() added parameter "@rc"
> 12:55:00.685500 dbrpcsend()
> 12:55:00.685957 in dbfreebuf()
> Therefore, my questions are:
> 	- Am I calling the dblib API functions appropriately?
> 	- Is dbrpcsend() broken? 
> 	- Is the underlying FreeTDS API broken or just dblib? What's
> 	  the alternative;
> Appreciate any input list members can provide.
> Thanks.
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds


If you are not an intended recipient of this e-mail, please notify
the sender, delete it and do not read, act upon, print, disclose,
copy, retain or redistribute it.

Click here for important additional terms relating to this e-mail.


More information about the FreeTDS mailing list