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]
Related
I know the temporary table will be deleted after the connection is lost. But within that connection, I want to do something like
EXEC test;
SELECT * FROM #Final;
#Final is the temporary table created in the stored procedure. The stored procedure needs 30 seconds, and I want to check my #final without running stored procedure again.
If I run the script in that stored procedure, the #final can be reused in the connection. But how to use it after the EXEC test?
So, except for creating a real table, is it possible to SELECT * FROM #Final after EXEC test? If no, I'll use real table instead. Thanks!
Then you don't want a temporary table. Use either a global temporary table (##final) or a real table.
Then delete the results after you run the procedure.
I should note that the stored procedure can return a result set which you can insert into a table, using exec().
Use a global temporary Table
create proc demo as
begin
select * into ##temptable from original_table
end
exec demo;
select * from ##temptable
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').
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
I am trying to use a stored procedure that contains two different cursors as table input like such:
INSERT INTO table1 EXEC * FROM tblDailySales
The stored proc contains two cursors - I did not run just using.
I get the following error:
A cursor with the name 'csrDistricts' does not exist.
I also, get this error
An INSERT EXEC statement cannot be nested
The stored proc contains no EXEC that I can see.
What kind of stored proc other than simple SELECT can be used as source for table?
Is table1 already defined? If so all you should have to do is
INSERT INTO table1
EXEC storedProcedureName
Now, the trick is, the stored procedure will only be able to return one result set and insert into the table.
If you need to insert two different result sets, you'll have to gather then in two different stored procedures, then run two INSERT statements.
If you must do them at once, you'll need to do the insert from within the stored procedure.
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.