I want a stored procedure that does the equivalent of the following
CREATE PROCEDURE Reset
AS
BEGIN
DELETE * FROM SomeTable;
DELETE * FROM SomeOtherTable;
END
and also returns some indicator of success or failure. How would I do that? Only way I can think of is pre-calculating the number of rows that should be affected, but that seems so shoddy.
The following will produce a success/failure indicator based on the question, 'did the table reset complete without failure?'. It's wrapped in a transaction so that both deletes happen or none happen, which keeps your data clean.
BEGIN TRY
BEGIN TRANSACTION;
DELETE FROM SomeTable;
DELETE FROM SomeOtherTable;
COMMIT TRANSACTION;
-- success indicator
SELECT 1 AS Result
END TRY
BEGIN CATCH
IF ##TRANCOUNT > 0
ROLLBACK TRANSACTION;
-- failure indicator
SELECT 0 AS Result
END CATCH
Related
I created this transaction (my first transaction), there is no row with Id = 111 in Teacher table, however it works on the Subject table and inserted a new row. Shouldn't it rollback all the changes?
BEGIN TRANSACTION
INSERT INTO Subject (Name, SupervisorId) VALUES('Statistics', 4)
UPDATE Teacher SET Name ='Hady' WHERE Id=111
COMMIT TRANSACTION
I then add some more logic to it, but still not working:
Begin Try
BEGIN TRANSACTION
INSERT INTO Subject (Name, SupervisorId) VALUES('Statistics', 4)
UPDATE TeacherO SET Name ='Hady' WHERE Id=111
COMMIT TRANSACTION
End Try
Begin Catch
ROLLBACK TRANSACTION
End Catch
If I understand this correctly, you assume, that the attempt to update a row in teacher table when there is no row with Id = 111 in Teacher table was an error...
An error occurs, when you do something forbidden or impossible. If you try to add a number to a string without casts. Or if you try to get hands on a not exisiting object. Maybe you want to convert 30.02.2016 to date. All will be an error.
But if you tell the database to update all rows where the id=111, exactly this happens: All rows with id=111 will be updated. The count of affected rows will be zero in your case. But this is not an error...
You have to use XACT_ABORT set option to ensure it rolls back. Without it some errors will not cause a roll back.
SET XACT_ABORT ON;
BEGIN TRY
BEGIN TRANSACTION;
INSERT INTO Subject (Name, SupervisorId) VALUES('Statistics', 4);
UPDATE TeacherO SET Name ='Hady' WHERE Id=111;
COMMIT TRANSACTION;
END TRY
BEGIN CATCH
ROLLBACK TRANSACTION;
END CATCH
Following is a SQL Server stored procedure. There is on start of transaction and there are two commits as you can see below. Is this valid (start is in while loop and 1st commit is in same while loop, but 2nd commit is in 2nd while loop)? If not what could be the solution to do it?
Please help.
IF EXISTS (SELECT * FROM sys.objects WHERE type = 'P' AND name = 'DELETE_COBOC_DATA')
DROP PROCEDURE DELETE_COBOC_DATA
GO
CREATE PROCEDURE DELETE_COBOC_DATA #ORGDN VARCHAR(100), #CHUNK VARCHAR(10)
AS
BEGIN
-- some code that executes before while
WHILE (#NUM_ROWS_TMPTRADMIN > 0)
BEGIN
BEGIN TRANSACTION
-- executes some code
COMMIT TRANSACTION
END
-- some more code
WHILE #NUM_ROWS_TMPDIR > 0
BEGIN
-- code code code
COMMIT TRANSACTION
-- code code code
END
-- some more code here as well
END
As I know this is allowed in MySQL
You cannot commit the same transaction twice. You can have nested transactions, but you cannot have "partial" commits, that is contradictory to the notion of a transaction (it's all-or-nothing). If both commits are executed, the second one will throw an error
The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION
MSSQL 2005 .I want to get a lock on a table at the start of transaction and only release it at the end of the transaction
BEGIN TRANSACTION;
-- get lock
BEGIN TRY
END TRY
BEGIN CATCH
IF ##TRANCOUNT > 0 BEGIN
ROLLBACK TRANSACTION;
-- release lock
END
END CATCH;
IF ##TRANCOUNT > 0 BEGIN
COMMIT TRANSACTION;
-- release lock
END
GO
Does lock on table gets automatically released once transaction has completed or rolledback?
Table locks, or other types of locks, can be set using hints like so:
UPDATE Users WITH (TABLOCK) SET Username = 'fred' WHERE Username = 'foobar'
Locks will generally expire when the command completes (even if the transaction is not yet done), unless you add other hints to keep them around within the scope of the transaction. See http://msdn.microsoft.com/en-us/library/ms187373%28v=sql.90%29.aspx for an explanation of all lock types and other table hints.
Locks will affect other users depending on the isolation level of their own transactions. See http://msdn.microsoft.com/en-us/library/ms173763%28v=sql.90%29.aspx for more info.
I have some code that has a purely sequential flow, without transaction.
I sandwich them with a begin transaction and commit transaction
begin transaction
......--My code here......
......
......--code to create Table1
......
ALTER TABLE [dbo].[Table1] WITH CHECK ADD CONSTRAINT [FK_constraint] FOREIGN KEY([field1], [field2])
REFERENCES [dbo].[Table2] ([field3], [field4])
GO
....
......--End of My code here......
rollback transaction
commit transaction
when i run the script until just above "rollback transaction" in management studio, if a simple error occurs such as division by zero, I run "rollback transaction", all changes are rolledback without problem.
But if the alter table statement fails because Table2 doesn't exist, it then triggers further errors.
Msg 1767, Level 16, State 0, Line 2
Foreign key 'FK_Constraint references invalid table 'dbo.Table2'.
Msg 1750, Level 16, State 0, Line 2
Could not create constraint. See previous errors.
Msg 1767, Level 16, State 0, Line 2
Foreign key 'FK_xxxxxx' references invalid table 'Table1'.
When I run "rollback transaction", I got this error message "The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION." which is silly, because I DO HAVE a begin transaction on top!
Please tell me what went wrong. Any help would be much appreciated. Using SQL-Server 2008.
EDIT:
I added
SELECT ##TRANCOUNT;
before and after "ALTER TABLE [dbo].[Table1] WITH CHECK ADD CONSTRAINT"
....
SELECT ##TRANCOUNT;
ALTER TABLE [dbo].[Table1] WITH CHECK ADD CONSTRAINT [FK_constraint] FOREIGN KEY([field1], [field2]) REFERENCES [dbo].[Table2] ([field3], [field4])
GO
SELECT ##TRANCOUNT;
....
The results are 1 and 0 respectively. The alter table automatically rollbacks my transaction on error!? I can't understand this.
I think there's nothing you can do about Sql Server treatment with DDL error severity handling, some of it are handled automatically (forcibly rolling back transaction for example) by Sql Server itself.
What you can just do is make your script code cope around it and provide script users with descriptive error.
An example:
-- drop table thetransformersmorethanmeetstheeye
-- select * from thetransformersmorethanmeetstheeye
-- first batch begins here
begin tran
create table thetransformersmorethanmeetstheeye(i int); -- non-erring if not yet existing
-- even there's an error here, ##ERROR will be 0 on next batch
ALTER TABLE [dbo].[Table1] WITH CHECK ADD CONSTRAINT [FK_constraint] FOREIGN KEY([field1], [field2])
REFERENCES [dbo].[Table2] ([field3], [field4]);
go -- first batch ends here
-- second batch begins here
if ##TRANCOUNT > 0 begin
PRINT 'I have a control here if things needed be committed or rolled back';
-- ##ERROR is always zero here, even there's an error before the GO batch.
-- ##ERROR cannot span two batches, it's always gets reset to zero on next batch
PRINT ##ERROR;
-- But you can choose whether to COMMIT or ROLLBACK non-erring things here
-- COMMIT TRAN;
-- ROLLBACK TRAN;
end
else if ##TRANCOUNT = 0 begin
PRINT 'Sql Server automatically rollback the transaction. Nothing can do about it';
end
else begin
PRINT 'Anomaly occured, ##TRANCOUNT cannot be -1, report this to Microsoft!';
end
-- second batch implicitly ends here
The only way this happens is if there is no open transaction in that SPID.
That's it. And the only way there's no open transaction is that either:
You never started a new transaction after the old one committed or rolled back
You have another commit or rollback somewhere you didn't notice
Something killed your connection or forced a rollback from outside your spid (like a kill command from another session)
You don't provide much code. Is there any error trapping or any other conditional logic in your query that's not shown?
As far as I know, the ALTER TABLE command will create its own new transaction, and when it fails, will rollback that transaction. A single rollback within a proc will cause all the open transactions within that proc to be rolled back. So you're seeing the error because the failure of the ALTER TABLE statement is implicitly rolling back your transaction before you try to do it..
You can confirm this easily enough by checking the #TRANCOUNT within your code, and only calling rollback when it is not zero
The error from the ALTER TABLE statement is a compile error rather than a runtime error - and so the whole batch in which that statement occurs is never executed. I'm guessing that there's no GO between BEGIN TRANSACTION and ALTER TABLE - hence the BEGIN TRANSACTION never executed, and what SQL Server is telling you is perfectly true.
Try adding a GO immediately after the BEGIN TRANSACTION.
Given this:
create table z
(
i int identity(1,1) not null,
zzz int not null
);
When you try the following..
begin try
begin transaction
alter table z drop column aaa;
commit tran;
end try
begin catch
print 'hello';
SELECT
ERROR_NUMBER() as ErrorNumber,
ERROR_MESSAGE() as ErrorMessage;
IF (XACT_STATE()) = -1
BEGIN
PRINT
N'The transaction is in an uncommittable state. ' +
'Rolling back transaction.'
ROLLBACK TRANSACTION;
END;
end catch
print 'reached';
..the error can be caught:
ErrorNumber ErrorMessage
4924 ALTER TABLE DROP COLUMN failed because column 'aaa' does not exist in table 'z'.
But try changing alter table z drop column aaa; to alter table z add zzz int;, Sql Server can catch the error..
Column names in each table must be unique. Column name 'zzz' in table
'z' is specified more than once.
..but won't yield back the control to you, CATCH block will not be triggered. Seems there's no hard and fast rules what errors are catch-able and which are not.
To illustrate the difference, here's the error catch-able by your code
Here's an error un-catch-able by your code, which is similar to your problem.
Notice that there's no grid there(via SELECT ERROR_NUMBER() as ErrorNumber, ERROR_MESSAGE() as ErrorMessage;). That means, Sql Server did not yield back the control to you after it detected an exception.
Maybe you can see other details here that might help: http://msdn.microsoft.com/en-us/library/ms179296.aspx
See this guideline for error handling ##ERROR and/or TRY - CATCH
By the way, on Postgresql all kind of DDL errors are catch-able by your code.
do $$
begin
-- alter table z drop column aaa;
alter table z add zzz int;
exception when others then
raise notice 'The transaction is in an uncommittable state. '
'Transaction was rolled back';
raise notice 'Yo this is good! --> % %', SQLERRM, SQLSTATE;
end;
$$ language 'plpgsql';
Here's the dev-rendered error message for alter table z drop column aaa; on Postgresql:
Here's the dev-rendered error message for alter table z add zzz int; on Postgresql; which by the way in Sql Server, when it has an error on this type of statement, it won't yield back the control to you, hence your CATCH sections are sometimes useful, sometimes useless.
I have been trying to find info on the web about the differences between these statements, and it seems to me they are identical but I can't find confirmation of that or any kind of comparison between the two.
What is the difference between doing this:
BEGIN
-- Some update, insert, set statements
END
and doing this
BEGIN TRANS
-- Some update, insert, set statements
COMMIT TRANS
?
Note that there is only the need to rollback in the case of some exception or timeout or other general failure, there would not be a conditional reason to rollback.
BEGIN and END deal with code blocks. They are similar to the curly braces you see in many languages:
if (somethingIsTrue)
{ // like BEGIN
// do something here
} // like END
In SQL, this is:
if somethingIsTrue
BEGIN
-- do something here
END
BEGIN TRAN, COMMIT, and ROLLBACK begin and end transactions. They do not specify a new block of code; they only mark the transaction boundaries.
Note that you can write a BEGIN TRAN and COMMIT in separate blocks of code. For example, if you want code to be part of a transaction, but you don't want to start a new one if the code is already in a transaction, you can do something like this:
declare #TranStarted bit = 0
if ##trancount = 0
begin
set #TranStarted = 1
begin tran
end
-- ... do work ...
if #TranStarted = 1
begin
commit
set #TranStarted = 0
end
The regular BEGIN and END are not used for transactions. Instead, they are just for indicating that some block of code is a single unit, much like braces {} in C#/C++/Java.
If you have an IF statement or a WHILE loop that does 10 things, you need to enclose them in BEGIN/END so that SQL Server knows that that whole list of 10 statements should be executed as a part of that condition.
These 2 statements are entirely different.
BEGIN..END mark a block of code, eg in an if statement
IF #something = 1
BEGIN
-- Do something when #something is equal to 1
END
BEGIN TRANS..COMMIT TRANS wrap the enclosing block in a transaction, and depending on server settings will rollback the transaction if an error occurs.
It should be mentioned, that there is a Begin; in PostgreSQL, that also initiates a transaction block, which at first confused me.
http://www.postgresql.org/docs/9.0/static/sql-begin.html
"BEGIN initiates a transaction block, that is, all statements after a BEGIN command will be executed in a single transaction until an explicit COMMIT or ROLLBACK is given. By default (without BEGIN), PostgreSQL executes transactions in "autocommit" mode, that is, each statement is executed in its own transaction and a commit is implicitly performed at the end of the statement (if execution was successful, otherwise a rollback is done)."
I have not seen END TRANS
:)
i think we use END only for BEGIN keyword not for BEGIN trans
we use commit or rollback for BEGIN trans