This is a question related to the context when calling a stored procedure from one database in the context of another database.
Say I have a procedure created in the MainDB:
USE MainDB;
GO
CREATE PROCEDURE dbo.sp_mainproc
#Login nvarchar(50),
#Error INT OUTPUT
AS
BEGIN
-- many details left out...
-- Login as string must be captured in the xUser table to get
-- the personal settings for the user...
SET #_user_id = ( SELECT dbo.xUser.user_id
FROM dbo.xUser
WHERE dbo.xUser.login = #Login );
IF( #_user_id IS NULL )
BEGIN
-- The user with the given #Login is not present. Indicate the failure.
SET #Error = 2
RETURN (1)
END
-- Do something in the MainDB. Here the main reason for calling
-- the stored procedure is implemented.
-- Indicate the success when finishing.
SET #Error = 0
RETURN (0)
END
GO
Now, I want to call the procedure from another procedure in the AuxDB:
USE AuxDB;
GO
CREATE PROCEDURE dbo.sp_action
AS
BEGIN
-- Call the MainDB.dbo.sp_mainproc to do the action in the MainDB.
-- The login name must be passed, and possible error must be checked.
DECLARE #error INT
DECLARE #retcode INT
EXEC #retcode = MainDB.dbo.sp_mainproc
N'the_user',
#error OUTPUT
IF (#retcode <> 0)
BEGIN
-- Here the error must be signalized.
RETURN 1
END
-- Everything OK, let's continue...
RETURN 0
END
GO
My question is: When the MainDB.dbo.sp_mainproc is called from within AuxDB.dbo.sp_action, where the dbo.xUser table used in the sp_mainproc is searched for. Is the MainDB.dbo.xUser considered, or is the AuxDB.dbo.xUser searched for?
Thanks,
Petr
Procs are compiled, so it will refer to the object in the same database in which the dbo.sp_mainproc exists, because when the proc was created, it refers only to dbo.xUser, which doesn't have a database name part
(i.e. MainDB.dbo.sp_mainproc will use MainDB.dbo.xUser irrespective of which database that the proc is called from).
Related
I understand there is a regularly quoted answer that is meant to address this question, but I believe there is not enough explanation on that thread to really answer the question.
Why earlier answers are inadequate
The first (and accepted) answer simply says this is a common problem and talks about having only one active insert-exec at a time (which is only the first half of the question asked there and doesn't address the ROLLBACK error). The given workaround is to use a table-valued function - which does not help my scenario where my stored procedure needs to update data before returning a result set.
The second answer talks about using openrowset but notes you cannot dynamically specify argument values for the stored procedure - which does not help my scenario because different users need to call my procedure with different parameters.
The third answer provides something called "the old single hash table approach" but does not explain whether it is addressing part 1 or 2 of the question, nor how it works, nor why.
No answer explains why the database is giving this error in the first place.
My use case / requirements
To give specifics for my scenario (although simplified and generic), I have procedures something like below.
In a nutshell though - the first procedure will return a result set, but before it does so, it updates a status column. Effectively these records represent records that need to be synchronised somewhere, so when you call this procedure the procedure will flag the records as being "in progress" for sync.
The second stored procedure calls that first one. Of course the second stored procedure wants to take those records and perform inserts and updates on some tables - to keep those tables in sync with whatever data was returned from the first procedure. After performing all the updates, the second procedure then calls a third procedure - within a cursor (ie. row by row on all the rows in the result set that was received from the first procedure) - for the purpose of setting the status on the source data to "in sync". That is, one by one it goes back and says "update the sync status on record id 1, to 'in sync'" ... and then record 2, and then record 3, etc.
The issue I'm having is that calling the second procedure results in the error
Msg 50000, Level 16, State 1, Procedure getValuesOuterCall, Line 484 [Batch Start Line 24]
Cannot use the ROLLBACK statement within an INSERT-EXEC statement.
but calling the first procedure directly causes no error.
Procedure 1
-- Purpose here is to return a result set,
-- but for every record in the set we want to set a status flag
-- to another value as well.
alter procedure getValues #username, #password, #target
as
begin
set xact_abort on;
begin try
begin transaction;
declare #tableVariable table (
...
);
update someOtherTable
set something = somethingElse
output
someColumns
into #tableVariable
from someTable
join someOtherTable
join etc
where someCol = #username
and etc
;
select
someCols
from #tableVariable
;
commit;
end try
begin catch
if ##trancount > 0 rollback;
declare #msg nvarchar(2048) = error_message() + ' Error line: ' + CAST(ERROR_LINE() AS nvarchar(100));
raiserror (#msg, 16, 1);
return 55555
end catch
end
Procedure 2
-- Purpose here is to obtain the result set from earlier procedure
-- and then do a bunch of data updates based on the result set.
-- Lastly, for each row in the set, call another procedure which will
-- update that status flag to another value.
alter procedure getValuesOuterCall #username, #password, #target
as
begin
set xact_abort on;
begin try
begin transaction;
declare #anotherTableVariable
insert into #anotherTableVariable
exec getValues #username = 'blah', #password = #somePass, #target = ''
;
with CTE as (
select someCols
from #anotherTableVariable
join someOtherTables, etc;
)
merge anUnrelatedTable as target
using CTE as source
on target.someCol = source.someCol
when matched then update
target.yetAnotherCol = source.yetAnotherCol,
etc
when not matched then
insert (someCols, andMoreCols, etc)
values ((select someSubquery), source.aColumn, source.etc)
;
declare #myLocalVariable int;
declare #mySecondLocalVariable int;
declare lcur_myCursor cursor for
select keyColumn
from #anotherTableVariable
;
open lcur_muCursor;
fetch lcur_myCursor into #myLocalVariable;
while ##fetch_status = 0
begin
select #mySecondLocalVariable = someCol
from someTable
where someOtherCol = #myLocalVariable;
exec thirdStoredProcForSettingStatusValues #id = #mySecondLocalVariable, etc
end
deallocate lcur_myCursor;
commit;
end try
begin catch
if ##trancount > 0 rollback;
declare #msg nvarchar(2048) = error_message() + ' Error line: ' + CAST(ERROR_LINE() AS nvarchar(100));
raiserror (#msg, 16, 1);
return 55555
end catch
end
The parts I don't understand
Firstly, I have no explicit 'rollback' (well, except in the catch block) - so I have to presume that an implicit rollback is causing the issue - but it is difficult to understand where the root of this problem is; I am not even entirely sure which stored procedure is causing the issue.
Secondly, I believe the statements to set xact_abort and begin transaction are required - because in procedure 1 I am updating data before returning the result set. In procedure 2 I am updating data before I call a third procedure to update further data.
Thirdly, I don't think procedure 1 can be converted to a table-valued function because the procedure performs a data update (which would not be allowed in a function?)
Things I have tried
I removed the table variable from procedure 2 and actually created a permanent table to store the results coming back from procedure 1. Before calling procedure 1, procedure 2 would truncate the table. I still got the rollback error.
I replaced the table variable in procedure 1 with a temporary table (ie. single #). I read the articles about how such a table persists for the lifetime of the connection, so within procedure 1 I had drop table if exists... and then create table #.... I still got the rollback error.
Lastly
I still don't understand exactly what is the problem - what is Microsoft struggling to accomplish here? Or what is the scenario that SQL Server cannot accommodate for a requirement that appears to be fairly straightforward: One procedure returns a result set. The calling procedure wants to perform actions based on what's in that result set. If the result set is scoped to the first procedure, then why can't SQL Server just create a temporary copy of the result set within the scope of the second procedure so that it can be acted upon?
Or have I missed it completely and the issue has something to do with the final call to a third procedure, or maybe to do with using try ... catch - for example, perhaps the logic is totally fine but for some reason it is hitting the catch block and the rollback there is the problem (ie. so if I fix the underlying reason leading us to the catch block, all will resolve)?
I'm trying to create a stored procedure where I'm inserting a new office into the OFFICE table I have in my database.
I want to first check whether the office I'm trying to create already exists or not.
Here is some code from where I've gotten so far, but I'm not able to quite get it right. I would greatly appreciate some input.
CREATE PROCEDURE stored_proc_new_office
AS
BEGIN
DECLARE #office_id int
SELECT #office_id = (SELECT office_id FROM inserted)
IF NOT EXISTS (SELECT 1 FROM OFFICE WHERE office_id = #office_id)
BEGIN
ROLLBACK TRANSACTION
PRINT 'Office already exists.'
END
END
Here is a bare bones example of how you can use a stored procedure to insert a new record with a check to ensure it doesn't already exist.
create procedure dbo.AddNewOffice
(
#Name nvarchar(128)
-- ... add parameters for other office details
, #NewId int out
)
as
begin
set nocount on;
insert into dbo.Office([Name]) -- ... add additional columns
select #Name -- ... add additional parameters to match the columns above
where not exists (select 1 from dbo.Office where [Name] = #Name); -- ... add any additional conditions for testing for uniqueness
-- If nothing inserted return an error code for the calling app to use to display something meaningful to the user
if ##rowcount = 0 return 99;
-- return the new id to the calling app.
set #NewId = scope_identity();
return 0;
end
SQL Server 2014 (v12.0.5546) - I have a "master" stored procedure that I run a bunch of others from. If one errors out, I want it to print a line stating so.
I ran it today, and one of the stored procedures in the master stored procedure returned an error saying that the table insert I was trying had the wrong number of variables, but it did not print the error.
I thought that stored procedures returned 0 if successful, so anything other than that would mean an error. Am I wrong, or is there a flaw in my process?
FYI, I don't need it to stop running if it encounters an error, I just need it to spit out the error message so I know where it failed. This is going to grow to 20-30 stored procedures by the time it's all said and done.
Here is the master stored procedure:
ALTER PROCEDURE [dbo].[Master_CreateLoadTables]
AS
DECLARE #retval INT
-- Builds all tables required for the stored procedures
EXEC #retval = [BuildTables]
IF (#retval) = 0
BEGIN
SET #retval = 1
EXEC #retval = [Load_CustomerLookup]
IF (#retval) <> 0
PRINT 'Load of Customer Lookup Table Failed'
EXEC #retval = [Load_CustomerInvoices]
IF (#retval) <> 0
PRINT 'Load of Customer Invoice Tables Failed'
EXEC #retval = [Load_Payments]
IF (#retval) <> 0
PRINT 'Load of Payments Table Failed'
END
ELSE
PRINT 'Table Creation Failed'
I thought that stored procedures returned 0 if successful, so anything other than that would mean an error. Am I wrong, or is there a flaw in my process?
Stored procedures return whatever value you tell them to. If there is no return statement, then they return success, 0.
The generally accepted practice is to return 0 for success and an error code for failure. But that is not enforced.
You are referring to user stored procedures. You need to investigate how they work in your environment.
I also encourage you to put the body of the stored procedure in a begin/end block.
one of the stored procedures in the master stored procedure returned
an error saying that the table insert I was trying had the wrong
number of variables, but it did not print the error.
It seems this was a compilation error. The return code will not be set after compilation errors so the assigned variable will remain unchanged. For example:
CREATE PROC dbo.ExampleCompilationError
AS
SELECT * FROM dbo.ThisTableDoesNotExist;
GO
DECLARE #rc int = NULL;
EXEC #rc = dbo.ExampleCompilationError;
SELECT #rc;
GO
The return code is still NULL with this code.
You could surround each proc execution with TRY/CATCH, which will catch compilation errors and execution time errors in the inner scope:
BEGIN TRY
EXEC dbo.ExampleCompilationError;
END TRY
BEGIN CATCH
PRINT 'ExampleCompolationError failed';
END CATCH;
I'm getting a 1064 error when trying to call a stored function from within a stored procedure. It only happens on the line where I try to do this: SET account_id = get_account_id(user);. What is the problem and how can I fix it?
Account ID Stored Functions:
CREATE DEFINER=`aaron`#`%` FUNCTION `get_account_id`(user VARCHAR(255)) RETURNS int(11)
BEGIN
DECLARE xaccount_id INT DEFAULT 0;
#Get Account ID and place into variable used when calling stored procedure that builds the tree structure for the leaf node portfolio id
SELECT account_id
FROM rst_sessions.session_data
WHERE username = user
ORDER BY update_date DESC LIMIT 1
INTO xaccount_id;
RETURN xaccount_id;
END
Stored Procedure that is trying to call the stored Function:
CREATE DEFINER=`aaron`#`%` PROCEDURE `build_report_portfolio_list`(user VARCHAR(255))
READS SQL DATA
BEGIN
DECLARE portf_id INT;
DECLARE portf_name VARCHAR(255);
DECLARE str_portf_parent_list VARCHAR(455);
DECLARE done INT DEFAULT 0;
DECLARE account_id INT;
SET account_id = get_account_id(user);
END
I don't even know if it was possible what I was trying to do, which may have caused the error. But I found a work around by calling the SF as a parameter with the call to the SP and got it to do what I needed it to do.
Code is: CALL build_report_portfolio_list(get_account_id('username_here'));
I'm not talking about doing a "SET NOCOUNT OFF". But I have a stored procedure which I use to insert some data into some tables. This procedure creates a xml response string, well let me give you an example:
CREATE PROCEDURE [dbo].[insertSomeData] (#myParam int) AS
DECLARE #reply varchar(2048)
... Do a bunch of inserts/updates...
SET #reply = '<xml><big /><outputs /></xml>'
SELECT #reply
GO
So I put together a script which uses this SP a bunch of times, and the xml "output" is getting to be too much (it's crashed my box once already).
Is there a way to suppress or redirect the output generated from this stored procedure? I don't think that modifying this stored procedure is an option.
thanks.
I guess i should clarify. This SP above is being called by a T-SQL Update script that i wrote, to be run through enterprise studio manager, etc.
And it's not the most elegant SQL i've ever written either (some psuedo-sql):
WHILE unprocessedRecordsLeft
BEGIN
SELECT top 1 record from updateTable where Processed = 0
EXEC insertSomeData #param = record_From_UpdateTable
END
So lets say the UpdateTable has some 50k records in it. That SP gets called 50k times, writing 50k xml strings to the output window. It didn't bring the sql server to a stop, just my client app (sql server management studio).
The answer you're looking for is found in a similar SO question by Josh Burke:
-- Assume this table matches the output of your procedure
DECLARE #tmpNewValue TABLE ([Id] int, [Name] varchar(50))
INSERT INTO #tmpNewValue
EXEC [ProcedureB]
-- SELECT [Id], [Name] FROM #tmpNewValue
I think I found a solution.
So what i can do now in my SQL script is something like this (sql-psuedo code):
create table #tmp(xmlReply varchar(2048))
while not_done
begin
select top 1 record from updateTable where processed = 0
insert into #tmp exec insertSomeData #param=record
end
drop table #tmp
Now if there was a even more efficient way to do this. Does SQL Server have something similar to /dev/null? A null table or something?
Answering the question, "How do I suppress stored procedure output?" really depends on what you are trying to accomplish. So I want to contribute what I encountered:
I needed to supress the stored procedure (USP) output because I just wanted the row count (##ROWCOUNT) from the output. What I did, and this may not work for everyone, is since my query was already going to be dynamic sql I added a parameter called #silentExecution to the USP in question. This is a bit parameter which I defaulted to zero (0).
Next if #silentExecution was set to one (1) I would insert the table contents into a temporary table, which is what would supress the output and then execute ##ROWCOUNT with no problem.
USP Example:
CREATE PROCEDURE usp_SilentExecutionProc
#silentExecution bit = 0
AS
BEGIN
SET NOCOUNT ON;
DECLARE #strSQL VARCHAR(MAX);
SET #strSQL = '';
SET #strSQL = 'SELECT TOP 10 * ';
IF #silentExecution = 1
SET #strSQL = #strSQL + 'INTO #tmpDevNull ';
SET #strSQL = #strSQL +
'FROM dbo.SomeTable ';
EXEC(#strSQL);
END
GO
Then you can execute the whole thing like so:
EXEC dbo.usp_SilentExecutionProc #silentExecution = 1;
SELECT ##ROWCOUNT;
The purpose behind doing it like this is if you need the USP to be able to return a result set in other uses or cases, but still utilize it for just the rows.
Just wanted to share my solution.
I have recently come across with a similar issue while writing a migration script and since the issue was resolved in a different way, I want to record it.
I have nearly killed my SSMS Client by running a simple while loop for 3000 times and calling a procedure.
DECLARE #counter INT
SET #counter = 10
WHILE #counter > 0
BEGIN
-- call a procedure which returns some resultset
SELECT #counter-- (simulating the effect of stored proc returning some resultset)
SET #counter = #counter - 1
END
The script result was executed using SSMS and default option on query window is set to show “Results to Grid”[Ctrl+d shortcut].
Easy Solution:
Try setting the results to file to avoid the grid to be built and painted on the SSMS client. [CTRL+SHIFT+F keyboard shortcut to set the query results to file].
This issue is related to : stackoverflow query
Man, this is seriously a case of a computer doing what you told it to do instead of what you wanted it to do.
If you don't want it to return results, then don't ask it to return results. Refactor that stored procedure into two:
CREATE PROCEDURE [dbo].[insertSomeData] (#myParam int) AS
BEGIN
DECLARE #reply varchar(2048)
--... Do a bunch of inserts/updates...
EXEC SelectOutput
END
GO
CREATE PROCEDURE SelectOutput AS
BEGIN
SET #reply = '<xml><big /><outputs /></xml>'
SELECT #reply
END
From which client are you calling the stored procedure? Say it was from C#, and you're calling it like:
var com = myConnection.CreateCommand();
com.CommandText = "exec insertSomeData 1";
var read = com.ExecuteReader();
This will not yet retrieve the result from the server; you have to call Read() for that:
read.Read();
var myBigString = read[0].ToString();
So if you don't call Read, the XML won't leave the Sql Server. You can even call the procedure with ExecuteNonQuery:
var com = myConnection.CreateCommand();
com.CommandText = "exec insertSomeData 1";
com.ExecuteNonQuery();
Here the client won't even ask for the result of the select.
You could create a SQL CLR stored procedure that execs this. Should be pretty easy.
I don't know if SQL Server has an option to suppress output (I don't think it does), but the SQL Query Analyzer has an option (under results tab) to "Discard Results".
Are you running this through isql?
You said your server is crashing. What is crashing the application that consumes the output of this SQL or SQL Server itself (assuming SQL Server).
If you are using .Net Framework application to call the stored procedure then take a look at SQLCommand.ExecuteNonQuery. This just executes stored procedure with no results returned. If problem is at SQL Server level then you are going to have to do something different (i.e. change the stored procedure).
You can include in the SP a parameter to indicate if you want it to do the select or not, but of course, you need to have access and reprogram the SP.
CREATE PROCEDURE [dbo].[insertSomeData] (#myParam int, #doSelect bit=1) AS
DECLARE #reply varchar(2048)
... Do a bunch of inserts/updates...
SET #reply = '<xml><big /><outputs /></xml>'
if #doSelect = 1
SELECT #reply
GO
ever tried SET NOCOUNT ON; as an option?