FreeTDS Development Group

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

Gunther Van Butsele wrote:
> I've been collecting logging information to debug my problem with output
> parameters not getting filled in php using the freetds functions.
>  
> I've attached an archive with every bit of info I could gather:
>  
>    stored_procedure_creation.sql - The stored procedure itself
>    script.php - PHP script that calls the stored procedure
>    sql_profiler.log - MS SQL Profiler log entry for the call to the
> stored procedure
>    tdsdump.log - TDSDUMP log, probably most useful to you

We can see from the TDSDUMP log that the parameter value is being returned
to the client:  

token.c:526:processing result tokens.  marker is  ac(PARAM)
read.c:179:tds_get_string: reading 16 from wire to give 8 to client.
token.c:1526:processing result. type = 38(integer-null), varint_size 1
token.c:1547:processing result. column_size 1
token.c:1863:tds_get_data: column 0, type 38, varint size 1
token.c:1920:processing row.  column size is 1 

and I'm willing to believe db-lib makes the parameter available to the
application because src/dblib/unittests/rpc.c works.  So I think the
difficulty lies further up the stack.  

There was a problem some years back with output parameters.  The issue was
when, in the dbresults-dbnextrow loops, the parameter data are available. 
IOW, when is it safe to call dbretdata()?  The documented answer: after
dbresults returns NO_MORE_RESULTS.  

HTH.  

--jkl