I am new to SQL sever. Can anyone help me out on how to write a nested stored procedure in sql server 2008 that has output parameters?
You may check this: Nesting Stored Procedures Although an important note to quote
Although the nesting limit is 32 levels, SQL Server has no limit on
the number of stored procedures that can be invoked from a given
stored procedure, provided that the subordinate stored procedures do
not invoke other subordinate stored procedures and the maximum nesting
level is never exceeded.
Example:
CREATE PROCEDURE [dbo].[Test1]
#ID INT,
#Emp INT
AS
BEGIN
DECLARE #x UserDefinedTableVariable
EXEC #x = Test2
#SomeID = #ID
END
Related
i am trying to execute this scalar function and i tried a lot of approaches to achieve this but i get stuck
Create FUNCTION CalculateElementFunc()
RETURNS int
AS
BEGIN
DECLARE #ResultVar numeric(18,6)
DECLARE #eq nvarchar(MAX)
set #eq = '7.5/100*1258.236'
declare #expression nvarchar(max)
set #expression = #eq
declare #result int
declare #SQLString nvarchar(max)
Set #SQLString = N'Select #result = #expression'
exec sp_executesql #SQLString, N'#expression nvarchar(100)',
#expression,
#result = #result output
select #ResultVar = #result
if( #ResultVar <> ROUND( #ResultVar, 2 ,1))
set #ResultVar = cast( ROUND( #ResultVar, 2 ,1) + .01 as numeric(18,2))
RETURN #ResultVar
END
When i try to execute it
select dbo.CalculateElementFunc()
i get this error
Msg 557, Level 16, State 2, Line 1
Only functions and some extended stored procedures can be executed from within a function.
Please Advice
What you want to do is not recommended in SQL Server. First, it is really hard. As you have learned, a SQL Server function cannot execute dynamic SQL.
This is subtly in the documentation:
EXECUTE statements calling extended stored procedures.
exec and sp_executesql are not extended stored procedures.
What can you do? Here are some options:
Is a stored procedure instead of a UDF a possibility? Stored procedures can execute the dynamic SQL.
Can you get around the problem of expression evaluation? Perhaps dynamic SQL can be used one level up in your code.
You can execute an extended stored procedure that starts another transaction and executes the dynamic SQL. Think: really bad performance.
You can write a CLR extended function.
Limitations on SQL User Defined Functions:
Non-deterministic build in functions cannot be used in user defined functions. e.g. GETDATE() or RAND().
XML data type is not supported.
Dynamic SQL queries are not allowed.
User defined functions does not support any DML statements (INSERT, UPDATE, DELETE) unless it is performed on Table Variable.
We cannot make a call to the stored procedure. Only extended stored procedure can be called from function.
We cannot create Temporary tables inside UDFs.
It does not support Error Handling inside UDF. Although, we can handle errors (RAISEERROR, TRY-CATCH) for the statements which uses this function.
And it looks like you are using/calling a stored procedure inside your User Defined Function. It is not the expression that's bugging you, it's that stored procedure call.
Try to replace it with some logic to achieve your desired output.
Hope this is helpful. If it helps to solve your problem then don't forget to mark it as an answer.
I have stored proc in which I am calling another stored proc.
Declare #itemNumber varchar(20),#productID int
EXEC usp_find_productID
#itemNumber = '35677',
#productID = #productID OUTPUT
This sp returns productID in variable #productID but also as resultset table.
Can somebody tell me why is this happening?
I will bet you a donut that inside the stored procedure you will find something like:
SELECT #ProductID
And that the stored procedure is actually different on the two servers.
Of course we can't tell, because you didn't post the important part (the actual stored procedure code).
I have a stored procedure which is nested in several other stored procedure. Is there a way to tell (inside the internal stored procedure) which is the caller?
CREATE PROC int_proc
AS
SELECT int_name = OBJECT_NAME(##PROCID)
,ext_name = 'How can I tell which is the ext_proc name?'
,nestlevel = ##NESTLEVEL
GO
CREATE PROC ext_proc1
AS
SELECT ext_name = OBJECT_NAME(##PROCID),nestlevel = ##NESTLEVEL
EXECUTE int_proc
GO
CREATE PROC ext_proc2
AS
SELECT ext_name = OBJECT_NAME(##PROCID),nestlevel = ##NESTLEVEL
EXECUTE int_proc
GO
EXEC ext_proc1
EXEC ext_proc2
I'm using SQL-Server 2005
No, there isn't. The "stack" isn't available to us
Why do you need this? FYI, I pass in ##PROCID to a common error logging stored procedure. So there are some uses for this. But none natively in SQL
I have a SQL Server stored procedure; I need to capture the return value from the stored procedure. Is this the correct way of doing this?
declare valback varchar(30)
set valback = exec storeproc1
In this case, storeproc1 is my stored procedure.
To start, use proper T-SQL syntax:
declare #valback int;
exec #valback = storeproc1;
The only return type allowed for a stored procedure is int. Stored procedures return status via the return statement.
I somehow have a feeling that you really want something else, namely:
to have an OUTPUT parameter in the procedure:
declare #valback varchar(30);
exec storedproc1 #valback OUTPUT;
or capture the procedure result set via INSERT ... EXEC. See How to Share Data Between Stored Procedures.
The correct syntax is:
DECLARE #valback VARCHAR(30)
EXEC #valback = storeproc1
As per the documentation:
http://msdn.microsoft.com/en-us/library/ms188332.aspx
I have a stored procedure that returns a valueI call it from other stored procedures that need to retrieve this value. The calling stored procedure is inside a transaction, the stored procedure that returns the value (and actually creates the value and stores it in a table that no other proc touches) is not inside its own transaction, but would be part of the caller's transaction.
The question is this, what is the most efficient way of retrieving the return value of the stored procedure and storing it in a variable in the calling proc?
Currently I have the following and I'm wondering if its very inefficient?
DECLARE #tmpNewValue TABLE (newvalue int)
INSERT INTO #tmpNewValue EXEC GetMyValue
DECLARE #localVariable int
SET #localVariable = (SELECT TOP 1 newvalue FROM #tmpNewValue )
Isn't there a more straight forward way of doing this? Isn't this an expensive (in terms of performance) way?
My stored proc doesn't have an output param, it just returns a value. Would using an output param be faster?
For what it's worth I'm using MS SQL Server 2005
If your getting a single return variable then yes this is innefficent you can do:
declare #localVariable int
exec #localVariable =GetMyValue
select #localVariable
See How to Share Data Between Stored Procedures
By some reasons 'exec #localVariable =GetMyValue' is not working for me (MS SQL 2005), it's always return 0 value (They have the same issue).
My opinion is:
if you can change stored procedure, add output parameter.
else if you can remove procedure, rewrite it as a function.
else use table variable, as you do.
Is this proc returning a rowset of 1 row and 1 column or no rowset at all and you just want to capture the returncode?
If you want just the returncode then use Josh's method otherwise use a OUTPUT parameter sicne it will be much faster than what you are doing now
To Explain what I mean run this code
use tempdb
go
create proc GetMyValue
as
select 1
go
create table #temp (id int)
declare #localVariable int
insert #temp
exec #localVariable =GetMyValue
select #localVariable,* from #temp
Try this:
create proc AvilableSeats
as
declare #v1 int,#v2 int
exec #v1= determinPath_Capacity 1,'Sat-Tue',32
exec #v2=Student_fGroup '6/12/2009'
select #v1-#v2