When calling a SQL Server stored procedure from an external language (c# for example), the manner in which the call is coded is such that a given stored procedure can be entirely described in metadata and called using a generic function. Support for varying numbers of parameters between different procedures is facilitated by a parameters collection on the calling command object.
If one wanted to implement a similar capability entirely within SQL Server, if one uses sp_executesql
(a somewhat relevant example of which can be found here: Dynamic Search Conditions in T‑SQL)....you can get most of the way there, but the main problem is that the parameters in the function call must be hardcoded.
Example from the article:
EXEC sp_executesql @sql, @paramlist,
@orderid, @fromdate, @todate, @minprice,
@maxprice, @custid, @custname, @city, @region,
@country, @prodid, @prodname
In this example, the SQL statement is stored within @sql
, the parameters list is stored within @paramList
, and what follows is a list of the actual parameters.
Both @sql
and @paramList
are simple nvarchar
variables that can be set programmatically (by reading from metadata and assigning to variables), but the actual parameters themselves are hardcoded.
So, the question is:
Is there a way to specify the actual parameters & values such that the implementation of this entire function could be entirely generic?