(If the query returned the expected amount of affected rows)
COMMIT TRANSACTION
(If the query did not return the expected amount of affected rows)
ROLLBACK TRANSACTION
Note: I’ve been told before that this will lock the affected table(s) until the changes made are committed or rolled back, but after looking it up it looks like it depends on a lot of minor details. Just be careful if you use it in production.
You can also return * to see the changes, or add specific fields.
Like for example:
Begin; Update users Set first_name=‘John’ Where first_name=‘john’ Returning *;
Then your Rollback; Or Commit;
So you’d see all rows you just updated. You can get fancy and do a self join and see the original and updated data if you want. I like to run an identifying query first, so I know hey I should see 87 rows updated or whatever.
Haven’t had any issues with table locks with this, but we use Postgres. YMMV.
If for example a client application is (accidentally) firing doubled requests to your API, you might get deadlocks in this case. Which is not bad per se, as you don’t want to conform to that behaviour. But it might also happen if you have two client applications with updates to the same resource (patching different fields for example), in that case you’re blocking one party so a retry mechanism in the client or server side might be a solution.
Just something we noticed a while ago when using transactions.
For everyone’s sanity, please restrict access to the prod DB to like two people. No company wants that to happen to them, and no developer wants to do that.
I don’t use readonly with dbeaver, but I do have the prod servers set to automatically make transactions and have to hit a button to commit. Almost certain it asks confirmation that I want to make the changes to prod which is nice too (I rarely have to touch our sql server prod)
Just a funny story. All of our devs and even BAs used to have prod access. We all knew this was a bad idea and put in a process of hiring a DBA.
I think in the first two weeks the DBA screwed up prod twice. I can’t remember the first mess up but the second he had a lock on the database and then went to lunch.
We eventually hired two awesome DBAs to replace that one but oh boy.
Imagine being hired to help prevent people from fucking something up, only to fuck that thing up in your first week—not once, but twice. You’d think after the first time it wouldn’t happen again…
I would say you can expand that on the following criteria: 1) a lot of people can have read access, but only a few should have write access, and read access should be restricted to specific tables without PII. 2) The people with write access should go through a Change Approval process: they submit the SQL they’re going to run and someone else approves or denies it before it can be done. 3) Every piece of SQL that modifies a table should be annotated with a comment and the ticket number in it in which that change was approved. 4) You should be able to rollback any committed change within an hour of it happening.
Double/triple check the messages/console for results. Look good?
Commit;
Worried?
Rollback;
Just be sure to mind your transaction logs for long running queries and by all things holy be sure you’re not doing this to a live db with a ton of transactions since you’re basically pausing any updates until the commit or rollback on the affected tables
Had something like that happen to a local dev database (thankfully). A dev next me blurts out “how to I rollback an update in SQL server”? He was used to Oracle and how easy it is to rollback something. Had to explain that commit just happens in SQL server regardless of whether or not you put that commit line in.
Add comment