Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 1234»»»

How to Build Dynamic Stored Procedures Expand / Collapse
Author
Message
Posted Friday, April 18, 2003 12:00 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, November 5, 2013 9:05 AM
Points: 976, Visits: 59
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
Post #11502
Posted Thursday, April 24, 2003 8:14 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, July 28, 2005 2:06 PM
Points: 44, 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.




Post #59776
Posted Thursday, April 24, 2003 8:39 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, November 5, 2013 9:05 AM
Points: 976, Visits: 59
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
Post #59777
Posted Thursday, April 24, 2003 9:38 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, September 17, 2009 8:37 AM
Points: 163, 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






Post #59778
Posted Thursday, April 24, 2003 9:41 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, January 7, 2013 4:23 PM
Points: 95, Visits: 21
Is there a significant performance benefit to building dynamic SQL in a stored procedure instead of from within code?




Post #59779
Posted Friday, April 25, 2003 10:30 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, November 5, 2013 9:05 AM
Points: 976, Visits: 59
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
Post #59780
Posted Thursday, December 15, 2005 10:48 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Yesterday @ 2:41 PM
Points: 42, Visits: 381

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, '''', '''''')




Post #244737
Posted Friday, December 16, 2005 3:37 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, August 18, 2008 3:07 AM
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.
Post #244781
Posted Friday, December 16, 2005 5:51 AM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Saturday, September 27, 2014 12:26 PM
Points: 676, Visits: 433

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.

 




Post #244804
Posted Friday, December 16, 2005 7:09 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, August 20, 2012 11:56 AM
Points: 7, 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.

Post #244827
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse