Click here to Skip to main content
15,886,789 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I have a stored procedure that has a call to another stored procedure embedded. The procedure is returning the result set from the embedded procedure and I'm looking for a simple solution to stop this. I know that I can always use and output parameter but I would like to know if there is some way to alter the procedure syntax without having to change a bunch of code to reflect a new way to getting the correct return value.

Basically, the procedure creates a new 'Object' entry then logs the transaction.

The stored procedure in the EXECUTE statement returns a BIGINT which is what the procedure returns, not the desired value.

SQL
-- Insert
DECLARE @ObjectId INT;
DECLARE @UniversalId UNIQUEIDENTIFIER;
SET @UniversalId = NEWID();

INSERT INTO dbo.Object (ObjectTypeId, StatusId, UniversalId, DateCreated, LastModifiedDate, DisplayName)
VALUES (@ObjectTypeId, 1, @UniversalId, GETUTCDATE(), NULL, @DisplayName);
SET @ObjectId = CAST(SCOPE_IDENTITY() AS BIGINT); -- Value I want

-- Log transaction
EXECUTE dbo.SP_CreateTransactionLogEntry @ObjectId, @UniversalId, N'CREATE', @CreatingUser; -- Value I get

SELECT @ObjectId;

When I execute this through the management studio, I see two separate result sets. One containing the ObjectId which I want and one containing the a TransactionID from the second procedure call. The TransactionId is the value returned by the procedure call.

I have tried different C# calls. Both SqlCommand.ExecuteReader() and SqlCommand.ExecuteScalar() return the undesired result set.

To sum up, is there a way to return the correct value without using an OUTPUT parameter?
Posted

1 solution

Actually, the answer is very simple. ExecuteReader() is the correct call but that retrieves the first table (result set) from the call to the SP.

So, just call dr.NextResult() to get to the second table of returned data, DataReader.NextResult Method (Microsoft.VisualStudio.Data.Framework)[^]
 
Share this answer
 
Comments
Foothill 11-Jan-16 15:24pm    
That would certainly work. However, I already have substantial data access code in place around my sql calls and adding the NextResult() call is not feasible without a lot of rework. Trouble is that I made a minor change to have the CreateTransactionLogEntry procedure return a value. I guess reverting that modification and moving that result to an output parameter would require less rework.
ZurdoDev 11-Jan-16 15:26pm    
Ya, you'll have to judge which approach works better for you. But at least now you'll remember that DataReaders are used to retrieve multiple result sets so hopefully this helps somewhere down the road.
Foothill 11-Jan-16 15:44pm    
This did give me an idea. It was a simple solution to add an overloaded function to advance result sets without having to make major modifications. Thanks.
ZurdoDev 11-Jan-16 15:53pm    
Glad to hear it.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900