CREATE PROCEDURE spGetRecord (@param int) AS Declare @varID int SELECT @varID = field2 FROM SettingsTable WHERE ID = @param SELECT * FROM DataTable where ID = @varID

(of course this could be done with a nested SELECT statement, but this example should give you the general idea)

Now when you try to request a field in the recordset in your ASP page you can get the following error:

"Item cannot be found in the collection corresponding to the requested name or ordinal"

Now most people take another look at their table to verify that the field does exist and start to pull their hairs out because the field really exists in the table.

A similar thing can happen when you use statements like DELETE, INSERT, UPDATE, CREATE, etc. in your stored procedure. You get back a recordset, but it's not the correct one! When you execute the query in the query analyzer it does return the correct values, but your ASP page seems to have incorrect values, or no values at all.

This is because every SQL statement in a stored procedure, by default, sends back a special message informing that it has completed the statement. This special message, among other things, includes the "nn rows affected" message you've probably seen if you've executed SQL statements through SQL Server's Query Analyzer. When ADO gets back these messages, it has trouble differentiating between what SQL statement's values it should populate in the recordset. In the stored procedure in the example the results of the first SELECT @varID= statement are passed to the recordset. The results of the second select (the results we actually want!) are passed as well, as the next recordset, but not as the default recordset. (Of course, you can get to these results using the ADO Recordset's NextRecordSet method - read Using Multiple Recordsets for more information on the NextRecordset method).

Now that we know why this happens, let's see what we can do about it. Essentially, you have to tell SQL server not to return a message to the client for every completed SQL statement in the stored procedure. This can be accomplished via the SET NOCOUNT ON and SET NOCOUNT OFF statements like so:

CREATE PROCEDURE spTest AS SET NOCOUNT ON SELECT @nextID = nextID FROM SettingsTable SET NOCOUNT OFF SELECT * FROM DataTable where ID = @nextID

The SET NOCOUNT [ON | OFF] option tells SQL Server to return no information for the statements between the two lines. So always use SET NOCOUNT ON for statements that aren’t supposed to return any records!