Regarding Output Parameters and RETVAL: A change that appears to have begun around 4.3.

According to the documentation and previously posted comments, if a stored procedure returns only one Recordset, you could retrieve the RETVAL and Output Params right away. THIS IS NO LONGER THE CASE. Beginning around 4.3, you must always use the mssql_next_result() function if any recordset is returned at all.

If you consider the example posted below by fjortizATcomunetDOTes on 26-Dec-2001...

While using stored procedures on SQL EXPRESS (and perhaps on SQL Server), you have to specify the column names in SELECT, instead of asterisk (*). Or else you will get some big Unicode error.

That is, instead of "select * from table",use "select col1, col2 from table".

One more important thing, Before using mssql_execute, you MUST AND SHOULD use mssql_init. mssql_init will generate the MS Sql statement resource, which will be taken as input by mssql_execute. Here is an example,

After many attempt I resolved the return output of a store procedure on Win2003 box, MSSQL7 and PHP 4.3.I have problem to process the result from store procedure strCheckUser, and I must to set a R variable, that must be returned from the last select operation (Select @R as R) see below.

If you call a store procedure who binds data to an OUTPUT parameter on a SQL Server 7 or later no response will be produced, or an error perhaps.

From the Free TDS documentation:

Output Parameters

I'm not getting my output parameters returned, but I seem to be doing everything right!

That's not a question!

Microsoft SQL Server 7 with SP3, and later versions, quietly changed (which is to say, broke) how they respond to queries that execute stored procedures with output parameters. Earlier servers let you send a query like EXECUTE A @P OUTPUT and fetch the output parameter as a special result row (technique varying by library). Newer servers simply don't send back that data. To elicit output parameters from them, you have to use the RPC protocols such as the DB-Library dbrpcparam.

Output parameters are cryptic to get out. Here's two examples, one if you have no results returned from your stored procedure, one if you do have results returned:
<?php
/**
* using OUTPUT param with no results returned from stored procedure
*/
$outParamValue = 0;
mssql_bind($stmt, '@'.$outParamName, $outParamValue, $outParamType, $is_output = true);
mssql_execute($stmt, $skip_results = true);
/* N.B. If you don't use $skip_results = true you must use mssql_next_result as below **even if there are no results returned from the stored procedure** */
echo($outParamValue);

want to share with you that I had a hard time with mssql_execute on a platform that was running php using FastCGI. Well, I guess the problem was that mssql_init always returned null. So after investigating this, and plus the fact that I don't have total control over the platform, I gave up and used mssql_query instead.

Using the function below, it is possible to generate most stored procedure calls, with the added benefits that one doesn't have to worry to much about datatype mappings, and that the funtion return exception codes and error message. So here goes:

After initializing a stored procedure
with mssql_init, and binding all the
parameters (and return value if needed)
with mssql_bind, you can execute the
statement with mssql_execute.

Parameters:
- stmt: statement resource obtained with
mssql_init.

From here, you can use any of the other
mssql_* functions to retrieve the
recordsets as if you had called
mssql_query. Any T-SQL error will also
be reported in the same way. The
variables passed by reference for OUTPUT
and RETVAL parameters will be filled
with the right values.

will fail when you execute statement 2. Not only will it fail, but you won't get any results back from mssql_get_last_message(), so it's super-frustrating. The way around this is to rearrange the structure of your script so that stored procedures are executed sequentially.

Regarding the "stored procedure execution failed" errors mentioned in previous posts -- in addition to using the data source name as defined in freetds.conf under Linux, you may encounter this error when attempting to call a stored procedure after running a standard query with mssql_query()

Call mssql_free_result() before executing the stored procedure with mssql_execute() to clear this up.