Initially I had one stored procedure and everything was running good but the requirement has changed now and I would like to call multiple stored procedures and pass a parameter. I am using Execute SQL Task and here is my query where it calls only one stored procedure:
EXEC [dbo].[sp_TEST]
#Code =?
[PEDS].[up_InitialClear]
The above works well but I need to be able to call other stored procedure and pass the same parameter here. How can I call sp_TEST1, sp_TEST2 and pass the same parameter? Thanks
Simply execute them separately like below .
EXEC [dbo].[sp_TEST] #Code
EXEC [PEDS].[up_InitialClear] #Code
Related
If I have a master stored procedure that runs other stored procedures, do those stored procedures complete execution in the order they were listed?
Ex: p_master
exec p_sp1
exec p_sp2
exec p_sp3
Will p_sp1 complete execution before p_sp2 executes, and will p_sp2 complete execution before p_sp3 executes?
If not, is it possible to force this to behave this way?
Short answer: Yes
As an aside, if you execute the stored procedures individually (i.e. not inside a master stored procedure), you should execute them like this:
exec p_sp1
Go
exec p_sp2
Go
exec p_sp3
Go
Reference
I have a stored procedure called sp_Rep_QTR which expects the following parameters: #stardate, #endate.
Now what I want to do is the following: create a job which will EXEC the sp_Rep_QTR at a time (#active_start_time) provided and pass the #stardate, #endate parameters to the stored procedure.
The #stardate, #endate parameters will be passed to a stored procedure which will create the job - these are passed from a web page.
I am working with an SSRS Report that uses a stored procedure.
The stored procedure [after the Use ... Set ANSI NULLS On] starts with ALTER PROCEDURE ...
While I can understand the SQL in a stored procedure, I have never used one in an SSRS Report [I only use 'straight' SQL statements].
When I use SQL as my Dataset, I can copy that SQL into SSMS and run it and see the data it returns.
With this stored procedure, how do I execute it in SSMS to see the data it returns? The stored procedure has a sample 'EXEC ...' statement with all the parameters populated ... but when I run that - no data is returned.
The SSRS report runs fine, but I want to be able to work with the stored procedure in SSMS and see the data it is returning. My goal is to be able to run the stored procedure in SSMS and then tweak it.
How do I work with this stored procedure in SSMS so I can look at the output?
If you just want to execute the procedure in SSMS, locate it in the object browser ([DatabaseName]/Programmability/Stored Procedures). RIght-click the procedure and select 'Execute Stored Procedure'
Fill in the parameters and click OK and a script will be generated to run the procedure.
It's a bit overkill but at least everything is there and you can run it whenever you like.
If you want to edit the proc, right-click and choose modify, a new script will be created (the ALTER PROCEDURE script you mentioned). Make changes as required, run the script and that will modify the procedure, then execute the procedure to see the results.
Of course it would be safer to make a copy and edit that, you can also just run the body of the stored proc by commenting out the ALTER PROCEDURE statement until you are happy with it but you may have to declare and variables that are normally passed in as parameters.
The stored procedure [after the Use ... Set ANSI NULLS On] starts with
ALTER PROCEDURE ...
That's the Alter Procedure script. Use this to edit a stored procedure.
In other words, edit the SQL code you want to optimize, then run the whole script to save the changes.
How do I work with this stored procedure in SSMS so I can look at the
output?
In SSMS use the syntax for stored procedures:
EXEC myspname paramter1, parameter2, param...
Where parameter1, parameter2, etc. are the parameters described in the ALTER Procedure script, directly after the ALTER PROCEDURE myspname. Parameters are preceded by the # symbol.
As you type-in the EXEC procedure command pop-up hints should appear describing the parameter.
Without knowing the code to the stored procedure, it could be doing any number of things based on what is passed to it by parameter. A stored procedure can do DDL and DML queries, and does not necessarily have to select anything at all for output.
Consider the following stored procedure:
ALTER PROCEDURE Administration.SetAndRetrieveNewPurchaseOrderNumber
#PurchaseOrderNumber INT OUTPUT
AS
BEGIN
SET NOCOUNT ON
UPDATE Administration.KeyNumbers
SET PurchaseOrderNumber += 1
WHERE RowId = 1
SET #PurchaseOrderNumber = (SELECT kn.PurchaseOrderNumber
FROM Administration.KeyNumbers kn
WHERE kn.RowId = 1)
END
GO
I can use this easily from within my application by simply executing the procedure and passing in by reference a suitably named parameter.
I now find myself wanting to execute the procedure listed above in another stored procedure. I tried the following, but it doesn't appear to work (either with or without the # symbol in the parameter part of the stored procedure being called;
DECLARE #PurchaseOrderNumber INT
EXEC Administration.SetAndRetrieveNewPurchaseOrderNumber(#PurchaseOrderNumber)
What is the correct way to do this, or in reality should there be a separate procedure for use in circumstances like this that only produces a scalar result?
You need to add the output keyword when passing in the parameter.
For example:
Declare #output int;
Exec storedproc(#parameter output)
I have a simple stored procedure that has parameter
CREATE Procedure GetSupplierForTesting
(#SupplierId INT)
AS
SELECT SuppLabel
FROM Supplier
WHERE Supplier.SupplierId = #SupplierId
I am able to call it with the exec command inside another stored procedure like this
exec GetSupplierForTesting #SupplierId = 10
I came across an article that explains how sp_executesql is faster than exec. My problem is that I don't know how to call a stored procedure that has parameters with sp_executesql. I have tried this code
DECLARE #SupplierId INT = 10;
EXEC sp_executesql N'GetSupplierForTesting', N'#SupplierId INT', #SupplierId
but I am getting an error:
Procedure or function 'GetSupplierForTesting' expects parameter '#SupplierId', which was not supplied
The syntax you would need would be
DECLARE #SupplierId INT = 10;
EXEC sys.sp_executesql N'GetSupplierForTesting #SupplierId=#SupplierId',
N'#SupplierId INT',
#SupplierId=#SupplierId
But don't do this. It is utterly pointless. There is no magic performance increase to be expected from using sp_executesql to basically wrap the same exec statement and execute it at a different scope.
Just use
exec dbo.GetSupplierForTesting #SupplierId = 10
1
Performance issue is based on assumption that when you are using non-parametrized ad-hoc query, it (the string representing this query) will be different every time - because specific argument values are parts of query text.
Whilst parametrized query keeps it's body unchanged because in place of where ... and title="asdf" you have where ... and title = #title. Only contents of variable #title change. But query text persists and sql server realizes that there is no need to recompile it.
Non-parametrized query will be recompiled every time you change values used in it.
2
You are getting exception because your script does not pass any arguments to the stored proc.
Your script is: 'GetSupplierForTesting' - that's it.
By passing arguments to sp_executesql you are passing them to the scipt. Not to the sp used in script, but to the script itself. E.g.:
exec sp_executesql N'print #val', N'#val int', #val = 1
this script does utilize variable #val. Your - does not. It just contains name of the proc. So your script corrected should look like
exec sp_executesql
N'exec GetSupplierForTesting #Supplier = #Supplier_id_value',
N'#Supplier_id_value int',
#Supplier_id_value = 10
script contains code calling your sp and this code passes argument to sp with value taken from #Supplier_id_value variable
#Supplier_id_value is declared as int for internals of this script
value of 10 is passed to the argument of the script
3
Performance issue you are talking about is about ad-hocs, not SPs.
Another face of this issue is parameter sniffing problem. Sometimes with specific param values your script or SP should use another execution plan, different from the plan it used for previously passed param values.
Every time recompiled ("slowly executed") ad-hoc would be (re)compiled for sure and probably would get better execution plan while SP or parametrized query would probably not be recompiled and would use worse, less optimal execution plan and would finally perform much slower than "slow because of recompilation" ad-hoc query.
There are no "write this - and it will work slowly", "write that - and it will hurtle like a rocket" rules in sql. It all depends on many factors. Sometimes one would probably need specifically ad-hocs, sometimes - should avoid them totally.