SQL Server 2012存储过程输出被包含过程的结果集中断

Question

long time reader, first time poster.

We're observing something strange in our production instance of SQL Server 2012 after we migrated our application's databases from dev, to test, to production for our recent go-live.

We have a number of stored procedures are called from a WCF web service to do various operations; some return result sets, others do not.

Some of these procedures call other (sub) procedures within them. These sub procedures have defined OUTPUT parameters. When the parent procedures are called in dev and test, they execute as expected and the returned result set is the final select statement.

But in our production environment, the parent procedures ARE running to completion when called, but instead of returning the expected result set like before, they return the sub procedure's OUTPUT parameter.

Below is an example excerpt from one of our procedures that demonstrates the issue:

CREATE PROCEDURE [dbo].[CHANGE_USER_DEPTID]

@USERID VARCHAR(10),
@DEPTID VARCHAR(10)

AS
BEGIN

SET NOCOUNT ON;

DECLARE @ALTERNATEUSERID VARCHAR(10)
DECLARE @EMPLID INT

EXEC GET_ALTERNATEUSERID_SP @USERID, @ALTERNATEUSERID OUTPUT

SELECT @EMPLID = EMPLID FROM ACTIVEDIRECTORY_VW WHERE ALTID = @ALTERNATEUSERID

...DO SOME VARIOUS PROCESSING...

UPDATE DEPARTMENT_TABLE
SET EMPLID = ...
WHERE ...

END

Ok, so this procedure's final statement is an update, and in our dev and test environments, when this CHANGE_USER_DEPTID procedure is called, it simply returns "Command(s) Completed Successfully". But in our production environment, the procedure returns a result set; the @ALTERNATEUSERID which is the output parameter of the sub procedure. How is that possible? The main procedure is never even selecting that variable, and the main procedure doesn't even HAVE an output parameter defined.

This isn't a big deal on some of the calls in the WCF service, because the .NET method uses them in a cmd.ExecuteNonQuery() statement. But it IS causing problems for some others where we're expecting the final select statement to return a certain result set at the end of the procedure (an integer, for example), but instead it returns the output parameter of the sub procedure (say, a string), which is causing various things to blow up further down the line.

Has anyone ever experienced, or even heard of this issue?

Answer 1

To wrap this up:

It turned out that one of the child stored procedures inside the parent procedure (about three levels deep) had an extra SELECT statement at the end which someone had uncommented for testing purposes. That extra select statement was being returned all the way up the stack in the topmost stored procedure.