Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


How to Build Dynamic Stored Procedures


How to Build Dynamic Stored Procedures

Author
Message
Robert W Marda
Robert W Marda
Ten Centuries
Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)

Group: General Forum Members
Points: 1130 Visits: 82
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/rmarda/howtobuilddynamicstoredprocedures.asp



Robert W. Marda
SQL Programmer
Ipreo

bumbler
bumbler
SSC Rookie
SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)

Group: General Forum Members
Points: 48 Visits: 1
Just a quick note: when building dynamic SQL in a sproc, SQL Server will not usually cache the query plan unless you use one of the built-in stored procedures to execute the code. So, instead of simply writing this:

exec (@strSQL)

It is actually better over the long run to write this:

exec sp_executeSQL @strSQL

The one drawback here is that the sproc, sp_executeSQL, expects its parameter as nVarchar, so you will be limited to 4000 characters instead of 8000. See more than you need to know in BOL.

Thanks,
DH.



Robert W Marda
Robert W Marda
Ten Centuries
Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)

Group: General Forum Members
Points: 1130 Visits: 82
I don't think we currently use sp_executeSQL and I have used it only a few times. So I am not an expert with its use. We have many dynamic stored procedures in production that have more than 4,000 characters in the query built and some even exceed 8,000 characters. So being limited to 4,000 is not an option. I tried to use the same technique I showed in example 2 of my article but couldn't get it to work so it appears there is no way to extend the max beyond 4,000 characters, where as with the EXEC command I don't know of a limit to how many varchar(8000) variables you can add together at the time you execute the code and so your code is theoretically not limited.

The trade off is that you lose benefit of most if not all caching done by SQL Server. For us this hasn't been a problem since most of what we have in production completes within a few seconds of execution with or without caching. It will depend on your individual situation if you can accept this type of performance or not.

Robert W. Marda
SQL Programmer
bigdough.com
The world’s leading capital markets contact database and software platform.



Robert W. Marda
SQL Programmer
Ipreo

Rajesh Patavardhan
Rajesh Patavardhan
SSC-Enthusiastic
SSC-Enthusiastic (173 reputation)SSC-Enthusiastic (173 reputation)SSC-Enthusiastic (173 reputation)SSC-Enthusiastic (173 reputation)SSC-Enthusiastic (173 reputation)SSC-Enthusiastic (173 reputation)SSC-Enthusiastic (173 reputation)SSC-Enthusiastic (173 reputation)

Group: General Forum Members
Points: 173 Visits: 119
One more difference between EXEC and sp_executesql is that first one does not allow you to run parameterized queries.

sp_executesql allows you to parameterize the sql and inturn helps in caching and re-use of execution plans.

The issue related to dynamic sqls, parameterized sqls and memory is discussed in following link

http://www.sqlservercentral.com/forum/link.asp?TOPIC_ID=11407



kevkaz
kevkaz
SSC Journeyman
SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)

Group: General Forum Members
Points: 97 Visits: 21
Is there a significant performance benefit to building dynamic SQL in a stored procedure instead of from within code?



Robert W Marda
Robert W Marda
Ten Centuries
Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)

Group: General Forum Members
Points: 1130 Visits: 82
Unless you manage to get an execution plan that can be reused (and usually you don't) then you can say there is no performance benifit.

For me, the benefit is that no changes have to be made to the web site or internal applications for most changes in the stored procedure. Particularly useful when I find a quicker way to get the same result set.

You could realize a slight performance benifit because you would not have to send thousands of characters from the client to the server. With the dynamic SP you simply send the call and the code is built server side and then immediately executed.

Robert W. Marda
SQL Programmer
bigdough.com
The world’s leading capital markets contact database and software platform.



Robert W. Marda
SQL Programmer
Ipreo

mark hutchinson
mark hutchinson
Valued Member
Valued Member (70 reputation)Valued Member (70 reputation)Valued Member (70 reputation)Valued Member (70 reputation)Valued Member (70 reputation)Valued Member (70 reputation)Valued Member (70 reputation)Valued Member (70 reputation)

Group: General Forum Members
Points: 70 Visits: 446

1. There is a redundant condition check in your example. Once we start building the WHERE clause, we've already passed the first check, which would have prevented our getting down to the second check.

IF @LastName <> '' AND @NameID <> 0
...
RETURN
END
...
--Begin building WHERE clause
IF @LastName <> '' OR @NameID <> 0
...

2. As has already been mentioned, performance of a dynamic SP will be poorer than a static SP. It would make more sense to generate the SP externally and then import them in a SQL stream, or to hook directly into SQL Server and do it programmatically. There's been a lot of work done in the realm of code generation (heck, entire system generation) that could serve as a model for this. As with most things, we trade performance for flexibilty and vice versa.

3. It should be noted that SQLServer2005 removes the 8000 character limit. This alone should be worth the migration.

4. How does the following statement provide SQL injection attack protection?
SET @LastName = REPLACE (@LastName, '''', '''''')





Oli Wilkinson
Oli Wilkinson
Valued Member
Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)

Group: General Forum Members
Points: 73 Visits: 2
As someone who's had to maintain code embedded with char(10)s everywhere I can honestly say that the advice in the first section of this article is absolute tripe. It does NOT make it easier to read, nor does it make it easier to maintain.
cliffb
cliffb
Say Hey Kid
Say Hey Kid (709 reputation)Say Hey Kid (709 reputation)Say Hey Kid (709 reputation)Say Hey Kid (709 reputation)Say Hey Kid (709 reputation)Say Hey Kid (709 reputation)Say Hey Kid (709 reputation)Say Hey Kid (709 reputation)

Group: General Forum Members
Points: 709 Visits: 438

When printing out the SQL statements, CHAR(10) does indeed make it easier to read. Maintenance on any sproc that uses dynamic sql however, depends on the complexity of the code.

From the examples given, I see no reason to use dynamic sql. There is no top clause, you do not need to dynamically determine a table name. If your production stored procedurees are setup like this, I would redesign them to take advantage of the sql engine.





JL Dominguez-246595
JL Dominguez-246595
Grasshopper
Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)

Group: General Forum Members
Points: 11 Visits: 59

I don't see any advantage to using dynamic store procedures. Also, it would be more difficult to tune and troubleshoot dynamic stored procedures if they constantly change. In addition, data validation should be done at the client side and not on the server side to save yourself a round trip.


Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search