I am in a new role where I would be sometimes (rarely) required to run update queries on a production DBs.
The Tables mostly have 1000 to 10000 rows.<p>I might be required to update 1 to few rows those times.
I am not a SQL expert, but know a bit of it.<p>Generally I expect,
I would need to create a SELECT query first to identify the rows that I need to modify. SELECT query should exactly return the rows that need modifications, nothing more.<p>Then create an update query using the where clause above.
I was thinking of wrapping the update query in transaction and running the statements sequentially, while keeping track of no of rows modified, as well confirming the changes using SELECT query. like below:<p>BEGIN TRANSACTION t1;
UPDATE tablename
SET attr1='attr1', attr2='attr2'
WHERE Attr3='attr3' AND ID='10';
-- At this point no of rows modified should match the number of rows returned by our previous SELECT query
SELECT * from tablename where WHERE Attr3='attr3' AND ID='10';
-- Expected modification should be seen here.
COMMIT TRANSACTION t1;-- Commit if everything OK till here.<p>I will be using Azure SQL Database Query Editor to run the queries step by step.<p>What else do I need to be mindful about? I don't want to be the person who dropped entire customers table.
Best practice is not to run update queries on production DB<p>Too many things can go wrong...in fact nobody should have permissions to do so...if you think there is a danger the entire customers table might be dropped, backup the DB