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 12345»»»

Writing Dynamic Stored Procedure Expand / Collapse
Author
Message
Posted Saturday, May 30, 2009 11:52 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, September 18, 2013 6:40 AM
Points: 253, Visits: 79
Comments posted to this topic are about the item Writing Dynamic Stored Procedure
Post #726230
Posted Monday, June 1, 2009 12:56 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 7:33 AM
Points: 2,542, Visits: 2,410
Old style to write the WHERE condition.
I prefer to build a string ONLY with the true condition; it's more performing.
In a complex WHERE with useless condition may lead to a BIG consume of resources.
Post #726438
Posted Monday, June 1, 2009 1:26 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, August 11, 2014 9:52 AM
Points: 210, Visits: 378
Quick question is it only me or has the formatting of that article gone a bit haywire. I'm sure there shouldn't be HTML formatting tags appearing alongside the SQL example.

I used to use lots of CASE statements and IF branches to handle queries that needed to be dynamic but build on the server side using multiple proc params. For example something like this:

CREATE PROC test
@Stamp datetime,
@FirstName varchar(25) = NULL,
@Surname varchar(25) = NULL,
@Age int = NULL,
@Address1 varchar(40) = NULL

AS
BEGIN

DECLARE @Today BIT

SELECT @Today = CASE Datediff(day,@Stamp,getdate()) WHEN 0 THEN 1 ELSE 0 END

IF @Today = 1
BEGIN
SELECT FirstName, SureName, Age, Address1
FROM DAILY
WHERE FirstName = CASE WHEN @FirstName IS NULL THEN FirstName ELSE @FirstName END
AND Surname = CASE WHEN @Surname IS NULL THEN Surname ELSE @Surname END
AND Age = CASE WHEN @Age IS NULL THEN Age ELSE @Age END
AND Address1 = CASE WHEN @Address1 IS NULL THEN Address1 ELSE @Address1 END
END
ELSE
BEGIN
SELECT FirstName, SureName, Age, Address1
FROM HISTORICAL
WHERE FirstName = CASE WHEN @FirstName IS NULL THEN FirstName ELSE @FirstName END
AND Surname = CASE WHEN @Surname IS NULL THEN Surname ELSE @Surname END
AND Age = CASE WHEN @Age IS NULL THEN Age ELSE @Age END
AND Address1 = CASE WHEN @Address1 IS NULL THEN Address1 ELSE @Address1 END

END

But then I learnt a bit more about query plan caching and indexing and so if I have to do dynamic queries in the DB I would build them up using a string with only the columns and filters required and then use sp_executeSQL to run it.
Post #726447
Posted Monday, June 1, 2009 2:16 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: 2 days ago @ 5:30 PM
Points: 21, Visits: 70
Apart from the fact that this article is horribly mangled (which may of course not be the author's fault, but it doesn't help in making this article easily readable), it is also a rather bad advice. And I know because I had done the same a while ago but got corrected.

For details see http://sqlinthewild.co.za/index.php/2009/03/19/catch-all-queries
Post #726460
Posted Monday, June 1, 2009 2:22 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, July 14, 2014 9:16 AM
Points: 59, Visits: 95
I prefer to use Sunil's way of writing query when I have optional (can be null) parameters in the procedure. I don't see a logical reason to use CASE, or ISNULL statement.
Sunil example is not anything new. Like anything in live, this too have some good and bad sides. The good ones are that is very logical, easy to debug, don't have a problem of sql injection etc. But also have bad side like the one that it can't use the cached plan for the query. In the other side creating query dinamically as string and executing with sp_executesql have all the bad sides but one good and that is that can use cashed plan. In most of situation we should use the first one, becuase if has more good than bad sides. But it becomes very usefull to use second one when we search very big table with milions of records.
Post #726464
Posted Monday, June 1, 2009 2:52 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Tuesday, September 9, 2014 2:06 AM
Points: 1,768, Visits: 8,318
http://www.sommarskog.se/dyn-search-2005.html discusses this and many other similar methods



Clear Sky SQL
My Blog
Kent user group
Post #726476
Posted Monday, June 1, 2009 3:02 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, May 6, 2010 2:13 AM
Points: 2, Visits: 8
Yes, it is not good way to write dynamic procedures like this because of performance, but on other side this approach has one plus - it is good readable, so easy to understand when looking on code of procedure. Times ago i was doing it same way, but once database was growing much the penalties for uising this procedures were big.
Post #726480
Posted Monday, June 1, 2009 3:05 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, September 25, 2014 4:46 AM
Points: 1,070, Visits: 907
Excellent link Dave.

I had been going to say I could never get the @x = y or @x is null thing to work effectively - it always ends up scanning big tables rather than using decent indexes, but Erland seems to cover the whole subject in very good depth.






Post #726481
Posted Monday, June 1, 2009 3:54 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Tuesday, September 9, 2014 2:06 AM
Points: 1,768, Visits: 8,318
http://www.sommarskog.se/dynamic_sql.html This one is also very good discussing dynamic sql in general. Coincidently I posted to my blog a method for optimizing dynamic sql for Unbalanced data loads http://sqlandthelike.blogspot.com



Clear Sky SQL
My Blog
Kent user group
Post #726499
Posted Monday, June 1, 2009 5:42 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Tuesday, February 11, 2014 4:12 PM
Points: 2,007, Visits: 768
Gail's article a few month's back on catch-all queries covered this territory really well:

http://sqlinthewild.co.za/index.php/2009/03/19/catch-all-queries

Sunil's method is acceptable on small tables, but on larger tables this will choke a server. I think developers implement it in their test environment where tables have a thousand rows, and it does what it's supposed to do and returns quickly. So it goes to production where the million row tables are first encountered. That's when the stored procedure that runs in under a second during testing takes hours in actual use. Clustered index scan fun at its best.
Post #726543
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse