[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freetds
Subject:    Re: [freetds] Stored procedure output/return parameters
From:       "James K. Lowden" <jklowden () freetds ! org>
Date:       2008-04-30 14:30:10
Message-ID: 20080430103010.3765c646.jklowden () freetds ! org
[Download RAW message or body]

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
_______________________________________________
FreeTDS mailing list
FreeTDS@lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
[prev in list] [next in list] [prev in thread] [next in thread]