I have the following SP which works correctly when ran on its own:
USE [Orders]
GO
SET FMTONLY OFF;
CREATE PROCEDURE [dbo].[Get_Details_by_Type]
@isArchived varchar(10),
@Type varchar(50)
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
declare @sqlQuery nvarchar(max)
IF(@isArchived = 'ALL')
BEGIN
set @sqlQuery = 'SELECT * FROM [dbo].[Orders]
WHERE ' + @Type + ' != €
ORDER BY [IDNumber]'
exec sp_executesql @sqlQuery
END
ELSE
BEGIN
set @sqlQuery = 'SELECT * FROM [dbo].[Orders]
WHERE ' + @Type + ' != € AND [isArchived] = ' + @isArchived + ' ORDER BY [IDNumber]'
exec sp_executesql @sqlQuery
END
END
SET FMTONLY ON;
The problem I'm having is that when I add a DataSet for a SSRS report, it pulls no fields/columns in the Fields section. I'm guessing it's due to the dynamic SQL?
How can I resolve that?
The Problem
Stored procs which contain Dynamic Sql and Temp tables are the bane of wizards like SSRS and ORM generators like Linq2SQL and EF reverse engineering tools.
This is because the tools SET FMTONLY ON;
(or more recently, sp_describe_first_result_set
) prior to running the PROC, in order to derive the resultset schema produced by the PROC so that mappings for the ReportViewer UI can be generated. However, neither FMTONLY ON
nor sp_describe_first_result
actually execute the PROC.
e.g. the tool will do something like:
SET FMTONLY ON;
EXEC dbo.MyProc NULL;
Some Workarounds:
SET FMTONLY OFF;
as the first line in the PROC - this will force execution of the PROC. Revert the original PROC once done (although note your proc may fail because of null or dummy parameters passed in by the tool). Also, FMTONLY
is being deprecated
Here's an example of the last hack:
CREATE PROCEDURE [dbo].[Get_Details_by_Type]
@isArchived varchar(10),
@Type varchar(50)
AS
BEGIN
-- For FMTONLY ON tools only
IF 1 = 2
BEGIN
-- These are the actual column names and types returned by the real proc
SELECT CAST('' AS NVARCHAR(20)) AS Col1,
CAST(0 AS DECIMAL(5,3)) AS Col2, ...
END;
-- Rest of the actual PROC goes here
FMTONLY ON
/ sp_describe_first_result_set
are fooled by the dummy conditional and assumes the schema from the never-executed branch.
As an aside, for your own sanity, I would suggest that you don't SELECT *
in your PROC - rather explicitly list all the real column names returned from Orders
Finally, just make sure you don't include the SET FMTONLY ON;
statement in your proc (from your code above!)
END - Proc
GO **
SET FMTONLY ON; ** This isn't part of the Proc!
If anyone is still facing this issue, I solved what appears to be a similar problem with ssrs and dynamic sql.
sp_YourStoredProc @Parameter1....@ParameterN
BTW, I'm using SQL 2012
Hope this helps.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With