How to Suppress the SELECT Output of a Stored Procedure called from another Stored Procedure in SQL Server?

I'm not talking about doing a "SET NOCOUNT OFF". But I have a stored procedure which I use to insert some data into some tables. This procedure creates a xml response string, well let me give you an example:

CREATE PROCEDURE [dbo].[insertSomeData] (@myParam int) AS
DECLARE @reply varchar(2048)

... Do a bunch of inserts/updates...

SET @reply = '<xml><big /><outputs /></xml>'
SELECT @reply
GO

So I put together a script which uses this SP a bunch of times, and the xml "output" is getting to be too much (it's crashed my box once already).

Is there a way to suppress or redirect the output generated from this stored procedure? I don't think that modifying this stored procedure is an option.

thanks.

---

I guess i should clarify. This SP above is being called by a T-SQL Update script that i wrote, to be run through enterprise studio manager, etc.

And it's not the most elegant SQL i've ever written either (some psuedo-sql):

WHILE unprocessedRecordsLeft
  BEGIN
    SELECT top 1 record from updateTable where Processed = 0
    EXEC insertSomeData @param = record_From_UpdateTable
  END

So lets say the UpdateTable has some 50k records in it. That SP gets called 50k times, writing 50k xml strings to the output window. It didn't bring the sql server to a stop, just my client app (sql server management studio).

The answer you're looking for is found in a similar SO question by Josh Burke:

-- Assume this table matches the output of your procedure
DECLARE @tmpNewValue TABLE ([Id] int, [Name] varchar(50))

INSERT INTO @tmpNewValue 
  EXEC [ProcedureB]

-- SELECT [Id], [Name] FROM @tmpNewValue

I think I found a solution.

So what i can do now in my SQL script is something like this (sql-psuedo code):

create table #tmp(xmlReply varchar(2048))
while not_done
  begin
    select top 1 record from updateTable where processed = 0
    insert into #tmp exec insertSomeData @param=record
  end
drop table #tmp

Now if there was a even more efficient way to do this. Does SQL Server have something similar to /dev/null? A null table or something?

Answering the question, "How do I suppress stored procedure output?" really depends on what you are trying to accomplish. So I want to contribute what I encountered:

I needed to supress the stored procedure (USP) output because I just wanted the row count (@@ROWCOUNT) from the output. What I did, and this may not work for everyone, is since my query was already going to be dynamic sql I added a parameter called @silentExecution to the USP in question. This is a bit parameter which I defaulted to zero (0).

Next if @silentExecution was set to one (1) I would insert the table contents into a temporary table, which is what would supress the output and then execute @@ROWCOUNT with no problem.

USP Example:

CREATE PROCEDURE usp_SilentExecutionProc
@silentExecution bit = 0
AS
BEGIN
SET NOCOUNT ON;



DECLARE @strSQL VARCHAR(MAX);
		
SET @strSQL = '';

SET @strSQL = 'SELECT TOP 10 * ';

IF @silentExecution = 1
     SET @strSQL = @strSQL + 'INTO #tmpDevNull ';

SET @strSQL = @strSQL + 	
'FROM dbo.SomeTable	';

EXEC(@strSQL);




END
GO
END
GO

Then you can execute the whole thing like so:

EXEC dbo.usp_SilentExecutionProc @silentExecution = 1;
SELECT @@ROWCOUNT;

The purpose behind doing it like this is if you need the USP to be able to return a result set in other uses or cases, but still utilize it for just the rows.

Just wanted to share my solution.

I have recently come across with a similar issue while writing a migration script and since the issue was resolved in a different way, I want to record it. I have nearly killed my SSMS Client by running a simple while loop for 3000 times and calling a procedure.

DECLARE @counter INT
SET @counter = 10
WHILE @counter > 0 
BEGIN 
    -- call a procedure which returns some resultset
    SELECT  @counter-- (simulating the effect of stored proc returning some resultset)
    SET @counter = @counter - 1
END

The script result was executed using SSMS and default option on query window is set to show “Results to Grid”[Ctrl+d shortcut].

Easy Solution: Try setting the results to file to avoid the grid to be built and painted on the SSMS client. [CTRL+SHIFT+F keyboard shortcut to set the query results to file].

This issue is related to : stackoverflow query

Man, this is seriously a case of a computer doing what you told it to do instead of what you wanted it to do.

If you don't want it to return results, then don't ask it to return results. Refactor that stored procedure into two:

CREATE PROCEDURE [dbo].[insertSomeData] (@myParam int) AS
BEGIN
DECLARE @reply varchar(2048)

--... Do a bunch of inserts/updates...

EXEC SelectOutput
END
GO

CREATE PROCEDURE SelectOutput AS
BEGIN
SET @reply = '<xml><big /><outputs /></xml>'
SELECT @reply
END

From which client are you calling the stored procedure? Say it was from C#, and you're calling it like:

var com = myConnection.CreateCommand();
com.CommandText = "exec insertSomeData 1";
var read = com.ExecuteReader();

This will not yet retrieve the result from the server; you have to call Read() for that:

read.Read();
var myBigString = read[0].ToString();

So if you don't call Read, the XML won't leave the Sql Server. You can even call the procedure with ExecuteNonQuery:

var com = myConnection.CreateCommand();
com.CommandText = "exec insertSomeData 1";
com.ExecuteNonQuery();

Here the client won't even ask for the result of the select.

You could create a SQL CLR stored procedure that execs this. Should be pretty easy.

I don't know if SQL Server has an option to suppress output (I don't think it does), but the SQL Query Analyzer has an option (under results tab) to "Discard Results".

Are you running this through isql?

You said your server is crashing. What is crashing the application that consumes the output of this SQL or SQL Server itself (assuming SQL Server).

If you are using .Net Framework application to call the stored procedure then take a look at SQLCommand.ExecuteNonQuery. This just executes stored procedure with no results returned. If problem is at SQL Server level then you are going to have to do something different (i.e. change the stored procedure).

ever tried SET NOCOUNT ON; as an option?