Data is stored in the SQL database by month. For e.g. TableA_202002, TableA_202001 and so on. The frontend user selects the required Month and Year which is passed on as a parameter into a stored procedure. There maybe other parameters passed in to the SP. In the SP a dynamic query is constructed by including the parameters.
SET #p_SQL = 'SELECT * FROM TABLEA_' + #p_TableName
EXEC (#p_SQL)
I wanted to know if there is a better way of getting the data than building dynamic queries. Thanks
Related
We have an SSRS report that runs a simple stored procedure, with 2 single-value parameters passed to it. Both the SSRS report and the stored procedure executed in SSMS returns in < 1 second. However, in the course of the last 2 weeks, there's been one user who has had the report not load twice. I've tried clearing the stored procedure's execution plan to no avail, and finally fixed it by just adding a dummy clause (1=1) to the sp to get the plan to change. The report works for every other user, including myself. What would be causing this?
This might be 'parameter sniffing', in which SQL Server generates a query plan for a specific value of the parameter which works ok for that value but works very badly for some other values.
A trick to 'turn off' parameter sniffing is to have some local variables in the stored procedure that are assigned the parameter values before you use them.
CREATE PROCEDURE [GetAroundParameterSniffing]
#SomeID INT
AS
BEGIN
DECLARE #LocalSomeID INT;
SET #LocalSomeID = #SomeID;
SELECT *
FROM MyTable m
WHERE m.SomeID = #LocalSomeID;
END
This forces SQL Server to come up with a plan independent of the parameter value
I have this specific issue in Microsoft SSRS 2008:
I have to execute a stored procedure, which will return data with the same columns, but in different formats:
EXEC Main_SP
#View = .....
IF #View = Yearly,
BEGIN
EXEC SP_Yearly_Data
END
IF #View = Quarterly,
BEGIN
EXEC SP_Quarterly_Data
END
IF #View = Monthly,
BEGIN
EXEC SP_Monthly_Data
END
IF #View = Weekly,
BEGIN
EXEC SP_Weekly_Data
END
All the 4 procedures will have the same data structure, ie. the same columns, only the groupings will be different, and hence the number of rows will also differ.
Will this work successfully in SSRS ?
Is there a better way to do it?
And will the dataset in the SSRS Report Designer quickly refresh to provide me the data related to the #View parameter provided ?
Any suggestions will be greatly appreciated.
Please note that each of the 4 inner procedures have some 3-4 parameters, all identical.
You can use IF statements in your SQL query in SSRS reports. I don't see why your SQL wouldn't work.
However, I think it would be cleaner to create a master stored procedure that also takes the #View parameter in addition to the others and it would do the conditional branching and return the results. This would also allow you to run it as a stored procedure in your SSRS dataset instead of a SQL statement with a bunch of IF conditions in it.
When you change the parameter value you'll need to rerun the report but it will return the correct dataset instead of using the cached one because the value of the parameter will have changed.
I have a stored procedure, and it is executed perfectly, when i am using:
exec spSampleAmount 12212,0
Now i need to pass like "12212,12213,12214,12215" and these values coming from another query. How to pass this query result to a 2 argument stored proc.
exec spSampleAmount param1,param2;
param1 have set of values.
Store the output of first query in parameter. First declare the parameter and then assign the value of first query to that parameter then call exec command to execure the stored procedure.
DECLARE #V_Param1 VARCHAR(1000);
SELECT #V_Param1 = Rest of query
EXEC spSampleAmount #V_Param1, 0
if it is called by SSRS it's possible, i don't know exactly how it works, but it is.
You have 2 ways to call a stored procedure from ssrs, sql query and write execute. Or select execute stored procedure.
In that way you have the possibility to pass a selection from a multiple item selection combobox to the stored procedure and in your stored procedure do a : where myparam in (#paramreceived).
It should be also possible in .Net.
I tried to do that in tsql and i never succeeded, so i'm interrested too if there is a solution to that problem
In a stored procedure, I've to build my own SQL request(because tables names and some properties names are known only at execution time(parameters)).
So Basically I've something like this
EXECUTE IMMEDIATE WITH RESULT SET OFF 'My custom query which select one data'
Usually, I would use the INTO commands, but my parameter is recognized inside the Execute immediate, which seems logic.
(Before you ask: I cannot return this in a result set, the result set is used for another data(and the result of this EXECUTE IMMEDIATE will determine which query I will run(and must be returned)).
How would you approach this problem? I guess it's the same problem on SQL Server-... but I didn't tested on it
You could create a table in compiled Sql and then the dynamic Sql populates it, so that the compiled sql statement after the dynamic part can read the results and update them onto your output params.
Does anyone know of a way to append text to a stored procedure from within another stored procedure? I would like to do something like the following in SQL Server 2005:
Declare str as Nvarchar(Max) = ''
set #spStr = dbo.spTest + 'Where testCol1 = ''Test'''
exec(#spStr)
I understand this may open some discussion about SQL injection attacks. I'm simply looking to see if syntax exsists to extend a stored procedure by passing it a where clause dynamically in the above manner.
There is no syntax like this available in Sql Server any version. You've got a couple of options:
You could obviously modify the procedure to include a parameter that the procedure code itself would handle as a filter in the final statement(s) that returned the result set from the procedure call. Though I'd advise against it, you could certainly have a parameter that was just a varchar/nvarchar data type which included the actual 'where' clause you want to add and have the procedure code append it to these final select statement(s) as well
Use the insert/exec syntax to populate a temp table with the results of the stored procedure execution and then simply run a filtered select against that temp table.
There are some options.
You can alter the actual SP using the metadata in INFORMATION_SCHEMA.ROUTINES (not really what I think you are wanting to be doing)
You can parameterize the SP - this should not be vulnerable to injection if the SP uses the variable directly and not to dynamically make SQL.
You might consider using a view or an inline or multi-step table-valued function instead, which can be used like a parameterized view (inline being more efficient) - SELECT * FROM udf_Test WHERE TestCol1 = 'Test'.
You can take the results of the SP and put them in a temporary table or table variable and query against that.