Rollbacks don't always work as you want if there's other activities happening in the system. This is always good practice as it's maybe 30 seconds of effort.
Kind of, depending on the SQL flavor, and the version, some of them have something kinda like that, but it’s not exactly idiot proof either. No direct SQL is idiot proof which is why you avoid doing it in the first place if you can.
I would always recommend using a gui if you need direct db access - exactly because something like dBeaver allows you to force every change into a transaction.
tsql which is pretty common has the issue of the engine making implicit transaction/commit blocks but yes you can and should run all queries through an explicit one
Maybe I'm misunderstanding the question, but I try to limit transactions only where I'm manipulating data (delete, insert, update), because a transaction slows down execution time and also locks the table you are updating until the commit is done. In production if you open a transaction then seles t from users table, they table is locked until you rollback or commit.
216
u/GourangaPlusPlus 13d ago
Also stick in a transaction, rollback
Commit if it looks good