I have several stored procedures that all use the same set of parameters. Is there a way to define and save the parameter list as a reusable block of code? Something like this:
CREATE PROCEDURE test
Using StoredParameterList
AS
BEGIN
SQL Statement
END
Is this possible? It would make code maintenance easier if a parameter needed to be changed.
Well, sort of. I've never used them, but Sql Server supports something called User Defined Types. I suspect you can create a user-defined type that represents your parameter list and then just have one parameter on each procedure with UDT.
Related
When I execute one of my stored procedures manually, I have to populate several variables.
Most of the variables don't change each time it is run; is it possible to pre-populate the "Value" box so that it only needs to be changed when necessary?
I am reluctant to hard code in the script as there was a series of interlinked procedures which I need to keep dynamic
I'm going to go out on a limb here and guess that you're talking about SQL Server, and that you're executing your procedure through SSMS, because of your description of the graphical interface. In the future, please tag your question with the specific database platform that the question pertains to, and try to be responsive to early comments. You'll get answers much, much faster. (If I'm wrong, just undo the tagging I added to your question.)
Although stored procedures can contain variables, what you're talking about here are parameters; values that are passed into the procedure from the calling code or application.
Parameters can be defined with default values in their declarations.
CREATE OR ALTER PROCEDURE dbo.SomeProc (
#SomeBigIntegerValue bigint = 42
)
AS...
When default values exist, the parameter becomes optional for the caller. The procedure can now be called with or without explicit parameters. Either of these will run.
EXECUTE dbo.SomeProc;
EXECUTE dbo.SomeProc
#SomeBigIntegerValue = 37;
In the first instance, the procedure will use the default value, 42. In the second instance, it will use the parameter value, 37.
You'll note that I named the parameter in the call. That's a best practice, generally, to avoid confusion, but it also allows you to send the parameters in any order. If you don't name them, they will be interpreted in the order they're declared, so you run all manner of risks there.
If you choose to execute the procedure through the GUI, the default values won't be pre-populated, but you can see which parameters have defaults and which don't by expanding the Parameters tab under the procedure name in SSMS. I couldn't find an example with defaults, but it'll looks something like this:
If you want the procedure to use the default value, just tick the Pass Null Value check box.
(In case you're wondering, we have a truncate proc so that our ETL service accounts can have scaled back permissions without having to do fully-logged, row-by-row deletions...)
Is it possible (using only T-SQL no C# code) to write a stored procedure to execute a series of other stored procedures without passing them any parameters?
What I mean is that, for example, when I want to update a row in a table and that table has a lot of columns which are all required, I want to run the first stored procedure to check if the ID exists or not, if yes then I want to call the update stored procedure, pass the ID but (using the window that SQL Server manager shows after executing each stored procedure) get the rest of the values from the user.
When I'm using the EXEC command, I need to pass all the parameters, but is there any other way to call the stored procedure without passing those parameter? (easy to do in C# or VB, I mean just using SQL syntax)
I think you are asking "can you prompt for user input in a sql script?". No not really.
You could actually do it with seriously hack-laden calls to the Windows API. And it would almost certainly have serious security problems.
But just don't do this. Write a program in C#, VB, Access, Powerscript, Python or whatever makes you happy. Use an tool appropriate to the task.
-- ADDED
Just so you know how ugly this would be. Imagine using the Flash component as an ActiveX object and using Flash to collect input from the user -- now you are talking about the kind of hacking it would be. Writing CLR procs, etc. would be just as big of a hack.
You should be cringing right now. But it gets worse, if the TSQL is running on the sql server, it would likely prompt or crash on the the server console instead of running on your workstation. You should definitely be cringing buy now.
If you are coming from Oracle Accept, the equivalent in just not available in TSQL -- nor should it be, and may it never be.
Right after reading your comment now I can understand what you are trying to do. You want to make a call to procedure and then ask End User to pass values for Parameters.
This is a very very badddddddddddddddddddd approach, specially since you have mentioned you will be making changes to database with this SP.
You should get all the values from your End Users before you make a call to your database(execute procedure), Only then make a call to database you Open a transaction and Commit it or RollBack as soon as possible and get out of there. as it will be holding locks on your resources.
Imagine you make a call to database (execute sp) , sp goes ahead and opens a transaction and now wait for End user to pass values, and your end user decides to go away for a cig, this will leave your resources locked and you will have to go in and kill the process yourself in order to let other user to go and use database/rows.
Solution
At application level (C#,VB) get all the values from End users and only when you have all the required information, only then pass these values to sp , execute it and get out of there asap.
You can specify the parameters by prefixing the name of the parameter with the # sign. For example, you can call an SP like this:
EXEC MyProc #Param1='This is a test'
But, if you are asking if you can get away with NOT providing required parameters, the answer is NO. Required is required. You can make them optional by providing a default value in the declaration of the SP. Then you can either not pass the value or call it like this:
EXEC MyProc #Param1=DEFAULT
--OR
EXEC MyProc DEFAULT
I am trying to convert a big list of SQL statements into a PostgreSQL stored procedure that uses a variable, one that should be populated from the result of one SELECT.
If you want to see what has to be run, you can check it here
As far as I know PostgreSQL does not allow use to use variables inside stored procedures that are using SQL language, so I'm looking for solutions that would require a minimal number of changes.
It's much easier after you find the right syntax:
Here is the procedure definition for plpgsql language:
DECLARE myvar integer;
BEGIN
SELECT INTO myvar FROM ...;
-- use myvar
END;
The code seems to be pretty repetitive. Will EXECUTE be of any help? (manual about execute) (example and more information) It allows you to run predefined queries and create new ones on the fly.
I want to create a SQL Server stored procedure with a varying number of parameters. It is similar to "params" in C#.
How can I do it?
Put them in an XML and try OPENXML feature.
http://msdn.microsoft.com/en-us/library/ms186918.aspx
You cannot.
What you can do is provide a default value for some of your stored procedure parameters, so you don't have to specify them when calling your stored procedure.
If you're on SQL Server 2008 or up, you could also investigate the table-valued parameter (or here) - basically the ability to pass in a table of data to your stored procedure. Maybe that'll help.
can we create user define function with in stored procedure then end of the store procedure we need to delete that custom user define function.
You can but it could get messy.
Look at sp_executesql. This will allow you to run arbitrary SQL, including DDL. Creating and using UDF's in this way does seem a bit dangerous -- you'll need to make sure that there aren't any name conflicts with competing threads, and there's no way to get any kind of query optimization.
I'd double check your design to make sure there isn't another solution to this!
Dynamic SQL is the only way.
ALTER PROC ...
AS
...
EXEC ('CREATE FUNCTION tempFunc...')
...
EXEC ('DROP FUNCTION tempFunc')
...
GO
However:
if you have 2 concurrent executions it will fail because tempFunc already exists
if each udf definition is different, then you need random names
if you randomise the name, the rest of the code will have to be dynamic SQL too
a stored proc implies reuse so just persist it
your code will need ddl_admin or db_owner rights to create the udf
...
So... why do you want to do this?