I have a stored procedure which executes another procedure inside it. The second one sometimes takes a while to run but the first seems to finish before waiting for the second. This has resulted in missing data, which should have been updated by the second procedure. Is there a timeout limit within the first procedure and can this be extended?
create a new table:
LogInfo
LogID int auto number/identity primary key
LogDate date default current date and time
LogValue string
in each procedure add INSERTs like this:
INSERT INTO LogInfo (LogValue) VALUES ('starting procedure A')
...
INSERT INTO LogInfo (LogValue) VALUES ('Calling procedure B')
...
INSERT INTO LogInfo (LogValue) VALUES ('ending procedure A')
then do this
SELECT * FROM LogInfo ORDER BY LogID
to see what happened, hopefully you will see this because procedures run sequentially and B can not finish after A:
starting procedure A
Calling procedure B
starting procedure B
ending procedure B
ending procedure A
You are understandably mistaken. Stored procedures execute synchcronously. For a variety of reasons, however, the results of the inner procedure may not be visible to an external process until after they have actually occurred. This may be why you are seeing whatever you are seeing that leads you to belive the order of completion is not in synch.
I would suspect that the inner stored procedure is in fact finishing/exiting as stored procedures run sequentially and symmetrically.
You might try scripting the outer stored procedure and drop it into Management Studio, remove the Create Procedure declaration, replace the arguments with Declare and add SET statements to set them to the values you are using on your test run. In addition, put Print statements after the call to the inner stored procedure and see if it completes.
Related
I have a stored procedure that returns this result:
The way I call the stored procedure is:
Exec uspGetStandardUsingRoleandPhase '1908003'
I want to store these results into a temp table so I used insert into like this:
IF OBJECT_ID(N'tempdb.dbo.#tmp', N'U') IS NOT NULL
DROP TABLE #tmp
CREATE TABLE #tmp
(
startDate DATE,
endDate DATE,
strPhase NVARCHAR(50),
strBadgeNumber NVARCHAR(30)
)
INSERT INTO #tmp (startDate, endDate, strPhase, strBadgeNumber)
EXEC uspGetStandardUsingRoleandPhase '1908003'
But I get an error like this:
INSERT EXEC failed because the stored procedure altered the schema of the target table.
Hard to say without seeing the code to the stored procedure, but my guess is that the procedure also creates a temp table named #tmp. Try creating a temp table with a different name and running your INSERT EXEC into that, or post the code to the procedure so we can see it.
Worth noting this can also come up in SQL 2016 if you're using Query Store, and it happens to run a clean up during the procedure's execution. They suggest increasing the Query Store size to reduce the likelihood, but other than that, they're not planning to fix it for SQL 2016 (it's fixed in 2017)
https://support.microsoft.com/en-us/help/4465511/error-556-insert-exec-failed-stored-procedure-altered-table-schema
I'm trying to run a stored procedure that will truncate a table and load new records using an INSERT statement. When I run the procedure I see that it executed correctly. However, when I run a SELECT statement after the procedure ran, I notice that the table is unchanged by the stored procedure. Do I need to script the procedure differently?
I've reviewed other pages on similar stored procedure topics and scripted my procedure according to others' instructions. My procedure will run but appears to not do anything.
Here is my script:
CREATE OR REPLACE PROCEDURE test AS
BEGIN
EXECUTE IMMEDIATE 'truncate table [Schema].[My table name]'
insert into [Schema].[My table name] (FIELD_ONE, FIELD_TWO) SELECT FIELD_ONE, FIELD_TWO
FROM ANOTHER_TABLE
WHERE [MY CRITERIA]
END
I'm getting a message of "ORA-24344: success with compilation error" for the "Connection" category and "Executed Successfully" for the Statement. However, I don't see any change to [Schema].[My Table name]
I have a stored procedure inside which I am declaring a temporary table
DECLARE GLOBAL TEMPORARY TABLE session.temp_table
(
query_id INTEGER ,
Query varchar(8000)
) .
Is it possible to access the data in the temp table after sp execution? Requirement is to put my dynamic sql in temp table and after execution figure out what query is being executed in stored proc.
If the DGTT has "on commit preserve rows" and "on rollback preserve rows" and if the session remains open then the contents of the DGTT are accessible to that session after an sproc returns (and before the sproc runs again, if the DGTT has 'with replace').
I need to create a table, with many indexes that is scoped only to the running sproc.
I tried a table variable, but this doesn't seem to support indexes. A local temp table seems to create a 'real' table, and need to be explicitly dropped at the end of the proc, from which I'm inferring that it's also shared across concurrent runs and so would break.
What can I use to store data with indexes that is scoped only to the indicidual instance of the running sproc?
You don't need to worry about dropping the table. SQL Server does that automatically. As explained in the documentation:
A local temporary table created in a stored procedure is dropped automatically when the stored procedure is finished. The table can be
referenced by any nested stored procedures executed by the stored
procedure that created the table. The table cannot be referenced by
the process that called the stored procedure that created the table.
This is a result of the scoping rules for access to the temporary table.
I will admit, that in practice, I tend to explicitly drop temporary tables in stored procedures. The differences among:
create table temp
create table #temp
create table ##temp
are all too similar to rely on the fact that the second is dropped automatically, but the first and third are not. However, this is my "problem" and not a best practice.
Updated
The answer is don't worry at all since the temp table will be as if it was a local variable inside the stored procedure.
I wanted to make sure if the doubt I had was correct or not, so I made this test
create procedure TestTempData
as
begin
declare #date datetime = getdate()
if object_id('#testing') is not null
drop table #testing
create table #testing(
Id int identity(1,1),
[Date] datetime
)
print 'run at ' + format(#date,'HH:mm:ss')
insert into #testing([Date]) values
(dateadd(second,10,getdate())),
(dateadd(second,20,getdate())),
(dateadd(second,30,getdate()))
waitfor delay '00:00:15'
select * from #testing
end
then I ran this query
exec TestTempData
waitfor delay '00:00:02'
exec TestTempData
the result came as
run at 14:57:39
Id Date
1 2016-09-21 14:57:49.117
2 2016-09-21 14:57:59.117
3 2016-09-21 14:58:09.117
the second result
run at 14:57:56
Id Date
1 2016-09-21 14:58:06.113
2 2016-09-21 14:58:16.113
3 2016-09-21 14:58:26.113
If the concurrent runs will effect the #temp table, both results
should be the same which was not the case, It seems that the temp
table inside stored procedure acts like a local variable inside a
method.
Before chatting with Gordon Linoff
Since you mentioned that the temp table is shared across concurrent runs, your temp table should be unique for the current run.
Your stored procedure should look like this
create procedure YourProc(#userId int)
as
begin
if object_id('#temp' + #userId) IS NOT NULL
execute( 'DROP TABLE #temp' + #userId +'')
...
execute('insert into #temp' + #userId + 'values(...')
end
The above solution will ensure that no conflict will occur and no data will be lost since each execution will be unique per userId
you don't need to drop the table when you finish because it will be dropped automatically by it self
Hope this will help you
Please look at the code I created. The first block is my stored procedure that I created.
The second block is me running the code manually, bypassing the stored procedure.
The 3rd block is me running the code using the stored procedure.
When I run the code without the stored procedure, I get results. When I run the code via the stored procedure, I don't get anything, even though it's presumably the same code.
ALTER PROCEDURE [dbo].[uspCheckSaleVIN]
#VIN nvarchar(17)
AS
SELECT *
FROM Sales
WHERE VIN = #VIN
SELECT *
FROM Sales
WHERE (VIN = 09872345098723457)
GO
uspCheckSaleVIN 09872345098723457
Do it like:
uspCheckSaleVIN '09872345098723457'
This is because 09872345098723457 is numeric and leading zero is just truncated from literal. Of course it would work only if you have non zero leading digit.
Proof:
CREATE PROCEDURE test
#p VARCHAR(5)
AS
SELECT #p
GO
EXEC test 01234
EXEC test '01234'
Outputs:
1234
01234