The message mentions two settings. The first setting, ansi_nulls
, is remembered from when the stored procedure was created. Make sure it's on when you run create procedure
:
set ansi_nulls on
go
create procedure YourProc as ...
The second setting, ansi_warnings
, should be enabled on the connection that calls the procedure:
set ansi_warnings on
exec YourProc
Or alternatively, set ansi_warnings
inside the procedure:
create procedure YourProc
as
set ansi_warnings on
...
For more information see this MSDN article:
Stored procedures execute with the SET settings specified at execute
time except for SET ANSI_NULLS and SET QUOTED_IDENTIFIER. Stored
procedures specifying SET ANSI_NULLS or SET QUOTED_IDENTIFIER use the
setting specified at stored procedure creation time. If used inside a
stored procedure, any SET setting is ignored.
I found a solution. I did not properly split the values in the stored procedure with a UDF.
To pass multi-values correctly in this stored procedure, I would need to add the following code to the dataset parameter that I am using:
=join(Parameters!<your param name>.Value,",")
This is basically going to join multiple values into an array and pass it through the @Flag
parameter. The next step is adding SQL to the stored procedure to receive and digest the values correctly so it reads the values with the IN
clause.
Google search any UDF string parser online. There are many to choose from. I used dba_parseString_udf
from Michelle Ufford http://sqlfool.com.
Once I had my UDF installed, I can now alter my IN
clause to receive the new multi-valued parameter being passed by SSRS as follows:
WHERE [Flag] IN (SELECT * FROM dba_parseString_udf(@Flag, ','))
Therefore, SSRS will pass the following value:
@Flag = 'A,B,C'
Then my UDF will parse that string out correctly to:
A
B
C
And populate my @Flag
parameter correctly with SELECT * FROM UDF()...
Best Answer
You are looking at the wrong part of SQL Servers's output.
NOCOUNT
only controls the extra "row(s) affected" messages that are output afterSELECT
/INSERT
/UPDATE
/DELETE
/MERGE
operations, not the rowsets output of anySELECT
s that don't have a destination specified. You can see this if you set SSMS to show output as text:will produce the output:
or if you leave SSMS set to show output in grids, you'll get the grids in the results tab and the following in the messages tab:
There is no way (that I know of) to stop all rowsets being output by a stored procedure that wants to output them.
You can use the form
INSERT <table> EXEC <procedure> <params>
to put the output into a temporary table (then just drop the table or let it be dropped as your session ends) to hide the first set of results, but this has a number of significant limitations:The table must already exist, you can't do the equivalent of
SELECT <stuff> INTO <newtable> FROM ...
, which adds a chunk of extra code (to create the table)As with any other
INSERT
either the table must have the right number of columns or you need to specify the destination columns, and in either case they must, of course, be of compatible typesINSERT <table> EXEC ...
can not be nested, so this will break if the procedure any dependencies it may have also useINSERT <table> EXEC ...
It can only capture one result set, so won't work as you desire if the called procedure returns more than one
Another thing to note about
NOCOUNT
is that the called stored procedure may override the setting you specify by usingSET NOCOUNT {ON|OFF}
itself so it might output counts ignoring your setting and you'll need to check/reset it after each call to make sure it is how you want it (see Artashes's answer for how to use @@OPTIONS to check).