Given:
CREATE PROCEDURE [dbo].[my_storedproc]
#param1 int, #param2 varchar(100)
AS
<<whatever>>
GO
Are there known performance differences between these different execution methods?:
-- Method #1:
declare #param1 int = 1
declare #param2 varchar(100) = 'hello'
exec my_storedproc #param1, #param2
-- Method #2:
exec my_storedproc #param1=1, #param2='hello'
-- Method #3:
declare #param1 int = 1
declare #param2 varchar(100) = 'hello'
declare #procname nvarchar(100) = N'my_storedproc #param1, #param2'
declare #params nvarchar(4000) = N'#param1 int, #param2 varchar(100)'
exec sp_executesql #procname, #params, #param1, #param2
-- Method #4:
declare #procname nvarchar(4000) = N'my_storedproc #param1=1, #param2=''hello'''
exec sp_executesql #procname
-- Method #5:
declare #procname nvarchar(4000) = N'my_storedproc 1, ''hello'''
exec sp_executesql #procname
-- Method #6:
declare #procname nvarchar(4000) = N'my_storedproc 1, ''hello'''
exec (#procname)
"Why do you ask?" you ask? I am trying to find a way to generically execute stored procedures entirely based upon metadata, the controlling stored procedure that will physically execute all the other configured (in metadata) stored procedures knows nothing about them other than what is defined in the metadata. Within this controller SP, I cannot (in any practical sense) know and declare the specific physical parameters (with their required data types) required for every possible stored proc that might have to be called - I am trying to find a way to execute them entirely generically, while still hopefully maintaining decent performance (reusing query plans, etc).
There really shouldn't be a performance difference between the 6 options since they are all executing the stored procedure and not any SQL statements directly.
However, there is no better indication of performance than testing this on your own system. You already have the 6 test cases so it shouldn't be hard to try each one.
Within this controller SP, I cannot (in any practical sense) know and declare the specific physical parameters (with their required data types) required for every possible stored proc that might have to be called
Why not? I don't see why you couldn't dynamically generate the SQL for Methods 2 and 3 based on the output of either of the following queries:
SELECT OBJECT_NAME(sp.[object_id]), *
FROM sys.parameters sp
WHERE sp.[object_id] = OBJECT_ID(N'dbo.my_storedproc');
SELECT isp.*
FROM INFORMATION_SCHEMA.PARAMETERS isp
WHERE isp.[SPECIFIC_NAME] = N'my_storedproc'
AND isp.[SPECIFIC_SCHEMA] = N'dbo';
And with that info, you could create a table to contain the various parameter values for each parameter for each proc. In fact, you could even set it up to have some parameters with "global" values for all variations and then some parameter values are variations for a particular proc.
Related
As described in title, I am trying to systematically get stored procedure pararameter names and their corresponding values inside the execution of the proper stored procedure.
First point, which is taking stored procedure parameter names, is easy using table [sys].[all_parameters] and the stored procedure name. However, getting the actual values of these parameters is the difficult part, specially when you are not allowed to use table [sys].[dm_exec_input_buffer] (as a developer, I am not allowed to read this table, since it is a system administrator table).
Here is the code I have so far, which I am sure can serve you as a template:
CREATE PROCEDURE [dbo].[get_proc_params_demo]
(
#number1 int,
#string1 varchar(50),
#calendar datetime,
#number2 int,
#string2 nvarchar(max)
)
AS
BEGIN
DECLARE #sql NVARCHAR(MAX);
DECLARE #ParameterNames NVARCHAR(MAX) = ( SELECT STRING_AGG([Name], ',') FROM [sys].[all_parameters] WHERE OBJECT_ID = OBJECT_ID('[dbo].[get_proc_params_demo]') )
SET #sql = N'SELECT ' + #ParameterNames;
DECLARE GetParameterValues CURSOR FOR
SELECT DISTINCT [Name] FROM [sys].[all_parameters] WHERE OBJECT_ID = OBJECT_ID('[dbo].[get_proc_params_demo]');
OPEN GetParameterValues;
DECLARE #param_values NVARCHAR(MAX) = NULL
DECLARE #StoredProcedureParameter NVARCHAR(MAX)
FETCH NEXT FROM GetParameterValues INTO #StoredProcedureParameter;
WHILE ##FETCH_STATUS = 0
BEGIN
SET #param_values = 'ISNULL('+#param_values+','')'+#StoredProcedureParameter+','
EXEC(#param_values)
FETCH NEXT FROM GetParameterValues INTO #StoredProcedureParameter;
END;
CLOSE GetParameterValues;
DEALLOCATE GetParameterValues;
SET #param_values = LEFT(#param_values, LEN(#param_values) - 1)
EXEC sp_executesql #sql,#ParameterNames,#param_values;
END
EXEC [dbo].[get_proc_params_demo]
#number1=42,
#string1='is the answer',
#calendar='2019-06-19',
#number2=123456789,
#string2='another string'
This is my approach trying to dynamically get parameter actual values inside a cursor, but it does not work, and I am clueless so far. I know it is quite rudimentary, and I am happy to hear other approaches. To be fair, I don't know if this problem is even possible to solve without system tables, but it would be great.
EDIT: This is an attempt to get a generic code that works on any stored procedure. You do not want to hardcode any parameter name. The only input you have is the stored procedure name via OBJECT_NAME(##PROCID)
I have a stored procedure which has several kind of parameters, INT, VARCHAR, DateTime, etc... This sp inserts a record into a log table with the parameters passed in. There are differents log tables, three exactly, which are called for example, LogTbl1, LogTbl2 and LogTbl3. This sp writes to LogTbl1, LogTbl2 or LogTbl3 depending on a sp parameter that indicates where to write to. I have set this parameter as tinyint and this takes as values 0, 1 or 2. Then depending on the value passed in, I build a dynamic query to write to the appropiate Log Table as below:
CREATE PROCEDURE [dbo].[spTraceLog]
#LogId int,
#param2 int,
#param3 int,
#param4 varchar(100),
#DateSent datetime,
#TargetTable tinyint = 0
AS
BEGIN
DECLARE #sqlCommand nvarchar(max)
DECLARE #tblName nvarchar(100)
SET #tblName = CASE #TargetTable
WHEN 0 THEN '[dbo].[LogTbl1]'
WHEN 1 THEN '[dbo].[LogTbl2]'
WHEN 2 THEN '[dbo].[LogTbl3]'
ELSE ''
END
IF #tblName <> ''
BEGIN
SET #sqlCommand =
'INSERT INTO ' + #tblName +
'([LogId]' +
',[param2]' +
',[param3]' +
',[param4]' +
',[Date]) ' +
'VALUES' +
'(#LogId' +
',#param2' +
',#param3' +
',#param4' +
',#DateSent)'
EXECUTE sp_executesql #sqlCommand
END
END
So is there any other better elegant way to do it? Not possible using an enumeration in the sp parameter #TargetTable?
Building up dynamic SQL then executing it means that Sql Server can't do a very good job of building an execution plan. This may impact efficiency and will matter most if the SP is called very frequently, which it looks like this SP will be.
Although the code would be less elegant I think it would be more efficient if your code had an if #TargetTable statement which contained three separate inserts which are all identical except for the table name you're inserting into.
But that doesn't answer the question. There is no enum and I don't think there is a problem with the type you've used to identify the log you want to write to. If you want the code to be more readable you could split it into three SPs and call them spTraceLog1, spTraceLog2 etc. and not pass in the TargetTable. I would avoid the dynamic SQL if possible.
I was wondering if I can make a stored procedure that insert values into dynamic table.
I tried
create procedure asd
(#table varchar(10), #id int)
as
begin
insert into #table values (#id)
end
also defining #table as table var
Thanks for your help!
This might work for you.
CREATE PROCEDURE asd
(#table nvarchar(10), #id int)
AS
BEGIN
DECLARE #sql nvarchar(max)
SET #sql = 'INSERT INTO ' + #table + ' (id) VALUES (' + CAST(#id AS nvarchar(max)) + ')'
EXEC sp_executesql #sql
END
See more here: http://msdn.microsoft.com/de-de/library/ms188001.aspx
Yes, to implement this directly, you need dynamic SQL, as others have suggested. However, I would also agree with the comment by #Tomalak that attempts at universality of this kind might result in less secure or less efficient (or both) code.
If you feel that you must have this level of dynamicity, you could try the following approach, which, although requiring more effort than plain dynamic SQL, is almost the same as the latter but without the just mentioned drawbacks.
The idea is first to create all the necessary insert procedures, one for every table in which you want to insert this many values of this kind (i.e., as per your example, exactly one int value). It is crucial to name those procedures uniformly, for instance using this template: TablenameInsert where Tablename is the target table's name.
Next, create this universal insert procedure of yours as follows:
CREATE PROCEDURE InsertIntValue (
#TableName sysname,
#Value int
)
AS
BEGIN
DECLARE #SPName sysname;
SET #SPName = #TableName + 'Insert';
EXECUTE #SPName #Value;
END;
As can be seen from the manual, when invoking a module with the EXECUTE command, you can specify a variable instead of the actual module name. The variable in this case should be of a string type and is supposed to contain the name of the module to execute. This is not dynamic SQL, because the syntax is not the same. (For this to be dynamic SQL, the variable would need to be enclosed in brackets.) Instead, this is essentially parametrising of the module name, probably the only kind of natively supported name parametrisation in (Transact-)SQL.
Like I said, this requires more effort than dynamic SQL, because you still have to create all the many stored procedures that this universal SP should be able to invoke. Nevertheless, as a result, you get code that is both secure (the #SPName variable is viewed by the server only as a name, not as an arbitrary snippet of SQL) and efficient (the actual stored procedure being invoked already exists, i.e. it is already compiled and has a query plan).
You'll need to use Dynamic SQL.
To create Dynamic SQL, you need to build up the query as a string. Using IF statements and other logic to add your variables, etc.
Declare a text variable and use this to concatenate together your desired SQL.
You can then execute this code using the EXEC command
Example:
DECLARE #SQL VARCHAR(100)
DECLARE #TableOne VARCHAR(20) = 'TableOne'
DECLARE #TableTwo VARCHAR(20) = 'TableTwo'
DECLARE #SomeInt INT
SET #SQL = 'INSERT INTO '
IF (#SomeInt = 1)
SET #SQL = #SQL + #TableOne
IF (#SomeInt = 2)
SET #SQL = #SQL + #TableTwo
SET #SQL = #SQL + ' VALUES....etc'
EXEC (#SQL)
However, something you should really watch out for when using this method is a security problem called SQL Injection.
You can read up on that here.
One way to guard against SQL injection is to validate against it in your code before passing the variables to SQL-Server.
An alternative way (or probably best used in conjecture) is instead of using the EXEC command, use a built-in stored procedure called sp_executesql.
Details can be found here and usage description is here.
You'll have to build your SQL slightly differently and pass your parameters to the stored procedure as arguments as well as the #SQL.
I've read that using Dynamic SQL in a stored procedure can hurt performance of your stored procedures. I guess the theory is that the store procedure won't store an execution plan for SQL executed via EXEC or sp_executesql.
I want to know if this is true. If it is true, do I have the same problem with multiple nested IF blocks, each one with a different "version" of my SQL statement?
If you have multiple nested IF blocks then SQL Server will be able to store execution plans.
I'm assuming that the IFs are straightforward, eg. IF #Parameter1 IS NOT NULL
SchmitzIT's answer is correct that SQL Server can also store execution paths for Dynamic SQL. However this is only true if the sql is properly built and executed.
By properly built, I mean explicitly declaring the parameters and passing them to sp_executesql. For example
declare #Param1 nvarchar(255) = 'foo'
,#Param2 nvarchar(255) = 'bar'
,#sqlcommand nvarchar(max)
,#paramList nvarchar(max)
set #paramList = '#Param1 nvarchar(255), #Param2 nvarchar(255)'
set #sqlcommand = N'Select Something from Table where Field1 = #Param1 AND Field2 = #Param2'
exec sp_executesql #statement = #sqlcommand
,#params = #paramList
,#Param1 = #Param1
,#Param2 = #Param2
As you can see the sqlcommand text does not hardcode the paramer values to use. They are passed separately in the exec sp_executesql
If you write bad old dynamic sqL
set #sqlcommand = N'Select Something from Table where Field1 = ' + #Param1 + ' AND Field2 = ' + #Param2
exec sp_executesql #sqlcommand
then SQL Server won't be able to store execution plans
This is what MSDN has to say about it. I highlighted the relevant bits to your question
sp_executesql has the same behavior as EXECUTE with regard to batches,
the scope of names, and database context. The Transact-SQL statement
or batch in the sp_executesql #stmt parameter is not compiled until
the sp_executesql statement is executed. The contents of #stmt are
then compiled and executed as an execution plan separate from the
execution plan of the batch that called sp_executesql. The
sp_executesql batch cannot reference variables declared in the batch
that calls sp_executesql. Local cursors or variables in the
sp_executesql batch are not visible to the batch that calls
sp_executesql. Changes in database context last only to the end of the
sp_executesql statement.
sp_executesql can be used instead of stored procedures to execute a
Transact-SQL statement many times when the change in parameter values
to the statement is the only variation. Because the Transact-SQL
statement itself remains constant and only the parameter values
change, the SQL Server query optimizer is likely to reuse the
execution plan it generates for the first execution.
http://msdn.microsoft.com/en-us/library/ms188001.aspx
I am attempting to make a stored procedure that uses sp_executesql. I have looked long and hard here, but I cannot see what I am doing incorrectly in my code. I'm new to stored procedures/sql server functions in general so I'm guessing I'm missing something simple. The stored procedure alter happens fine, but when I try run it I'm getting an error.
The error says.
Msg 1087, Level 15, State 2, Line 3
Must declare the table variable "#atableName"
The procedure looks like this.
set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
go
ALTER PROCEDURE [dbo].[sp_TEST]
#tableName varchar(50),
#tableIDField varchar(50),
#tableValueField varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE #SQLString nvarchar(500);
SET #SQLString = N'SELECT DISTINCT #aTableIDField FROM #atableName';
EXEC sp_executesql #SQLString,
N'#atableName varchar(50),
#atableIDField varchar(50),
#atableValueField varchar(50)',
#atableName = #tableName,
#atableIDField = #tableIDField,
#atableValueField = #tableValueField;
END
And I'm trying to call it with something like this.
EXECUTE sp_TEST 'PERSON', 'PERSON.ID', 'PERSON.VALUE'
This example isn't adding anything special, but I have a large number of views that have similar code. If I could get this stored procedure working I could get a lot of repeated code shrunk down considerably.
Thanks for your help.
Edit: I am attempting to do this for easier maintainability purposes. I have multiple views that basically have the same exact sql except the table name is different. Data is brought to the SQL server instance for reporting purposes. When I have a table containing multiple rows per person id, each containing a value, I often need them in a single cell for the users.
You can not parameterise a table name, so it will fail with #atableName
You need to concatenate the first bit with atableName, which kind defeats the purpose fo using sp_executesql
This would work but is not advisable unless you are just trying to learn and experiment.
ALTER PROCEDURE [dbo].[sp_TEST]
#tableName varchar(50),
#tableIDField varchar(50),
#tableValueField varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE #SQLString nvarchar(500);
SET #SQLString = N'SELECT DISTINCT ' + quotename(#TableIDField) + ' FROM ' + quotename(#tableName);
EXEC sp_executesql #SQLString;
END
Read The Curse and Blessings of Dynamic SQL
You cannot use variables to pass table names and column names to a dynamic query as parameters. Had that been possible, we wouldn't actually have used dynamic queries for that!
Instead you should use the variables to construct the dynamic query. Like this:
SET #SQLString = N'SELECT DISTINCT ' + QUOTENAME(#TableIDField) +
' FROM ' + QUOTENAME(#TableName);
Parameters are used to pass values, typically for use in filter conditions.