Something changed in the server of our client and I would like to know what it is. Previously when I committed a transaction (BEGIN TRAN ... COMMIT) it was committed immediately, without having to close the query window in SQL Server Management Studio.
Now when the transaction is executed, without closing the window, the message is "Query executed successfully" but actually the transaction is not being committed. When I press the "x" to close the query window a message appears, something like: "There are uncommitted transactions, do you wish to commit them? (Yes/No)" If I press "yes" the transaction is committed rightly.
My question is, why this happens? Where can one configure the option of committing the transactions only if the query window is closed? I would like to know before talking to the client. It seems they changed something.
Thanks.
This was caused by a mistake in the script that was being run. A COMMIT statement was missing in a nested transaction.
Related
I have disabled autocommit in SSMS.
I have been playing around with it today and after some bizarre (to me, anyway) behaviour narrowed the use case to the following:
connect to db
open a new a query (ctrl n)
issue a simple SELECT statement eg
select TOP (5) * from AdventureWorks2017.Person.Person
close the window
I get the following message in a dialog (dialogue, hmm) box:
There are uncommitted transactions. Do you wish to commit these transactions before closing the window?
Being a long-time Oracle user, I was aware there are differences in locking between Oracle and SS, but selects causing an outstanding transaction that needs to be committed or rolled back? Really? This can't be so, surely. No data has changed. Please could somebody explain? Thanks in advance.
When you're working with the console, it automatically puts your queries into a transaction. Because you haven't closed the transaction it automatically started when you started running queries of any kind, you still have a transaction open.
This MSDN article talks a bit about it.
https://learn.microsoft.com/en-us/sql/t-sql/statements/set-implicit-transactions-transact-sql
I used toad to connect to Oracle, issued a select query and while exiting it asked to issue commit or rollback. I pressed the escape key and the message box disappeared. Then I ended the connection. Will this cause any problems to the tables I queried? Will it cause the undo tablespace or rollback segment to go out of control?
Thanks in advance.
This is what the Oracle PMON (Process Monitor) process will handle. If a session is terminated in a disorderly manner, then the session will be left in a state that must be cleared up. The PMON process will then roll back any active transactions.
So to answer your question: No, your transaction is no longer active and all your changes were rolled back (if you did not explicitly commit).
I am connecting to a SQL Server using no autocommit. If everything is successful, I call commit. Otherwise, I just exit. Do I need to explicitly call rollback, or will it be rolled back automatically when we close the connection without committing?
In case it matters, I'm executing the SQL commands from within proc sql in SAS.
UPDATE: It looks like SAS may call commit automatically at the end of the proc sql block if rollback is not called. So in this case, rollback would be more than good practice; it would be necessary.
Final Update: We ended up switching to a new system, which seems to me to behave the opposite of our previous one. On ending the transaction without specifying committing or rolling back, it will roll back. So, the advice given below is definitely correct: always explicitly commit or rollback.
It should roll back on close of connection. Emphasis on should for a reason :-)
Proper transaction and error handling should have you always commit when the conditions for commit are met and rollback when they aren't. I think it is a great habit to always commit or rollback when done and not rely on disconnect/etc. All it takes is one mistake or incorrectly/not closed session to create a blocking chain nightmare for all :-)
I'm facing some locks at our DB server created by our application. What I don't understand is how a process that is Sleeping is having an Open Transaction (that process 71 is the one creating the Lock).
As far as I know when a process finishes it closes all the opened transactions. Is that rigth?
Thanks in advance mates.
As far as I know when a process
finishes it closes all the opened
transactions. Is that right?
No. If you explicitly open a transaction you must explicitly commit or rollback. Until that time the transaction remains open so it is perfectly possible for a connection to be idle (not currently processing any task) but still have an uncommitted transaction.
Many people expect that an error will automatically roll back a transaction but this is not the case unless you have
set xact_abort on
As far as I know when a process
finishes it closes all the opened
transactions. Is that rigth?
Yes. But it is not guaranteed and you should not rely on it. You must explicitly close the connection.
I have noticed something over the last few months. Each time we run a script that has a transaction statements let say we stop the query unexpectedly this action actually lock the database.
The only way out is to destroy the transaction each time. I have never experience this before even though I have stopped the query in the middle of transaction in the past and it has never locked the database.
Could it be that we are missing something in settings or I should not stop transaction queries unexpectedly?
The problem occurred with SQL SERVER 2005. please I need your brain. Thanks Guys
This is usual: you have sent a client abort which say "stop processing"
To rollback and release lock, you need to use SET XACT_ABORT ON
SO 1 and SO 2