Home/ Questions/Q 5954887
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-22T18:02:06+00:00

A specification essentially is a text string representing a where clause created by an

  • 0

A specification essentially is a text string representing a “where” clause created by an end user.

I have stored procedures that copy a set of related tables and records to other places. The operation is always the same, but dependent on some crazy user requirements like “products that are frozen and blue and on sale on Tuesday”.

What if we fed the user specification (or string parameter) to a scalar function that returned true/false which executed the specification as dynamic SQL or just exec (@variable).
It could tell us whether those records exist. We could add the result of the function to our copy products where clause.

It would keep us from recompiling the copy script each time our where clauses changed. Plus it would isolate the product selection in to a single function.

Anyone ever do anything like this or have examples? What bad things could come of it?

EDIT:

This is the specification I simply added to the end of each insert/select statement:

and exists (
    select null as nothing
    from SameTableAsOutsideTable inside
    where inside.ID = outside.id and      -- Join operations to outside table

          inside.page in (6, 7) and       -- Criteria 1
          inside.dept in (7, 6, 2, 4)     -- Criteria 2
)

It would be great to feed a parameter into a function that produces records based on the user criteria, so all that above could be something like:

and dbo.UserCriteria( @page="6,7", @dept="7,6,2,4")
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Dynamic Search Conditions in T-SQL

    When optimizing SQL the important thing is optimizing the access path to data (ie. index usage). This trumps code reuse, maintainability, nice formatting and just about every other development perk you can think of. This is because a bad access path will cause the query to perform hundreds of times slower than it should. The article linked sums up very well all the options you have, and your envisioned function is nowhere on the radar. Your options will gravitate around dynamic SQL or very complicated static queries. I’m afraid there is no free lunch on this topic.

    • 0