SQL Clone
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
SSCertifiable
SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)

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

Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems
bumbler
bumbler
SSC Journeyman
SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)SSC Journeyman (98 reputation)

Group: General Forum Members
Points: 98 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
SSCertifiable
SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)

Group: General Forum Members
Points: 5793 Visits: 140
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
Billing and OSS Specialist - SQL Programmer
MCL Systems
Rajesh Patavardhan
Rajesh Patavardhan
SSC Eights!
SSC Eights! (953 reputation)SSC Eights! (953 reputation)SSC Eights! (953 reputation)SSC Eights! (953 reputation)SSC Eights! (953 reputation)SSC Eights! (953 reputation)SSC Eights! (953 reputation)SSC Eights! (953 reputation)

Group: General Forum Members
Points: 953 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-Enthusiastic
SSC-Enthusiastic (125 reputation)SSC-Enthusiastic (125 reputation)SSC-Enthusiastic (125 reputation)SSC-Enthusiastic (125 reputation)SSC-Enthusiastic (125 reputation)SSC-Enthusiastic (125 reputation)SSC-Enthusiastic (125 reputation)SSC-Enthusiastic (125 reputation)

Group: General Forum Members
Points: 125 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
SSCertifiable
SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)

Group: General Forum Members
Points: 5793 Visits: 140
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
Billing and OSS Specialist - SQL Programmer
MCL Systems
mark hutchinson
mark hutchinson
SSC-Addicted
SSC-Addicted (480 reputation)SSC-Addicted (480 reputation)SSC-Addicted (480 reputation)SSC-Addicted (480 reputation)SSC-Addicted (480 reputation)SSC-Addicted (480 reputation)SSC-Addicted (480 reputation)SSC-Addicted (480 reputation)

Group: General Forum Members
Points: 480 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
SSC-Enthusiastic
SSC-Enthusiastic (121 reputation)SSC-Enthusiastic (121 reputation)SSC-Enthusiastic (121 reputation)SSC-Enthusiastic (121 reputation)SSC-Enthusiastic (121 reputation)SSC-Enthusiastic (121 reputation)SSC-Enthusiastic (121 reputation)SSC-Enthusiastic (121 reputation)

Group: General Forum Members
Points: 121 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
SSCrazy
SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)SSCrazy (2.2K reputation)

Group: General Forum Members
Points: 2177 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
SSC Journeyman
SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)

Group: General Forum Members
Points: 95 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