Comments on: Catch-all queries

By: Daniel

Daniel — Wed, 01 Sep 2010 06:04:09 +0000

I guess Walker’s query logic can be modified as such to handle the scenario when two or three parameters are passed.
WHERE ((key1 = @key1 AND @key1 IS NOT NULL) OR (@key1 IS NULL))
AND ((key2 = @key2 AND @key2 IS NOT NULL) OR (@key2 IS NULL))
AND ((key3 = @key3 AND @key3 IS NOT NULL) OR (@key3 IS NULL))

btw, this logic would be a better approach than the dynamic query..atleast for these types of situatios…

By: Emtucifor

Emtucifor — Mon, 19 Apr 2010 18:14:59 +0000

David Walker, your query isn’t logically the same. If 3 keys were passed in, your OR query would pull all rows where any one matches, not rows where all three match.

By: Gail

Gail — Fri, 13 Nov 2009 09:18:43 +0000

Main drawbacks of dynamic is security. Also the loss of syntax highlighting, compile time error checking and intellisense. It’s not something I’d use everywhere, just for the places it does work well (and this is one of them)

By: Michael

Michael — Thu, 12 Nov 2009 20:20:19 +0000

I thought that dynamic SQL was a worse choice than the catch-all option, but this article says otherwise ? I got a big chunk of dynamic sql from a contractor and it’s harder to follow than non-dynamic. What are the drawbacks of dynamic ?

By: David Walker

David Walker — Thu, 05 Nov 2009 16:40:56 +0000

I think you left out an important section from “Dynamic Search Conditions”. Instead of using this form:

WHERE (key1 = @key1 OR @key1 IS NULL)
AND (key2 = @key2 OR @key2 IS NULL)
AND (key3 = @key3 OR @key3 IS NULL

you should consider using this:

WHERE (key1 = @key1 AND @key1 IS NOT NULL)
OR (key2 = @key2 AND @key2 IS NOT NULL)
OR (key3 = @key3 AND @key3 IS NOT NULL)

As Erland Sommarskog says, “The odds are very good that SQL Server will generate a plan which seeks the three key indexes and then merges the result either by index concatenation or some other method. Here is the real big scoop: thanks to the condition, @x IS NOT NULL, SQL Server adds a filter with a startup expression to the plan, so if the corresponding variable is NULL, SQL Server will not access that index at all.”

I have found in my testing that this solution performs very well; indexes ARE used, performance is great, and dynamic code is not required.

By: Brian

Brian — Thu, 24 Sep 2009 23:17:19 +0000

Thank you so much for this article, it was very informative and extremely helpful. This is by far one of the most useful SQL articles I’ve read over the years!

By: Gail

Gail — Mon, 21 Sep 2009 19:35:10 +0000

I think that may depend on the server collation. AdventureWorks is case insensitive on my server (as are all of my DBs). After a rather nasty experience a few years back I’m allergic to case-sensitive databases

By: Ed

Ed — Mon, 21 Sep 2009 17:45:00 +0000

Gail – Nevermind I figured out my problem. The sample AdventureWorks DB is set to a case senative collation.

By: Ed

Ed — Mon, 21 Sep 2009 17:35:05 +0000

Gail, I must be missing something because I’ve tinkered with yoru example and no matter what I try I get errors. I repalced all the charatcers that did not copy over correctly like the single quotes but still it errors out on me.

By: Catch all queries and indexing - SQL and the like

Catch all queries and indexing - SQL and the like — Tue, 08 Sep 2009 09:59:47 +0000

[...] many others, Gail Shaw has blogged on the subject of catch all queries. On many occasions I have needed to do something similar and found performance to be pretty [...]