||Let's take a look at the following stored procedure. This procedure needs to get a value from the settingstable to get the record we want.|
CREATE PROCEDURE spGetRecord (@param int)
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
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
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
SET NOCOUNT ON
SELECT @nextID = nextID FROM SettingsTable
SET NOCOUNT OFF
SELECT * FROM DataTable where ID = @nextID
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!