It is really very bad of person to laugh on others misfortune, however dark humor is based on the same concept. It has been long time since I wrote something funny on this blog. Recently, I have came across forum discussion regarding backup misery of one of the developer. I feel very sorry for the DBA who lost their backup but I found the suggestions of other “SQL Experts” really humorous and helpful as well.
Read whole communication here
Some of the witty lines are :
OK, take a deep breath.
Write a resignation letter.
Go into your bosses office.
You might lose your job, but at least you’ll be respected more.
This is why I think database vendors should disable DROP and DELETE by default if a WHERE clause is not specified. However, in the event that you need to use a DROP or DELETE without a WHERE, you should have to provide an overriding keyword something like:
DROP COMMIT tablename/dbname
DELETE COMMIT tablename/dbname
Or just DELETE tablename WHERE 1 = 1.
If you are really serious about database backup here are many articles written about Database BackUp and Restore.
Reference : Pinal Dave (https://blog.sqlauthority.com)
I think, more importantly, this is a case that illustrates why not only backups are important but staging servers. I author and test all of my scripts on my development box before running them live (and still usually cringe when executing).
Of course at a job, a long time ago, I did a “rm *.*” instead of the “rm a:*.*” that I was supposed to do and wiped a whole terminal, and the guy I had to tell, the head of corporate IT, was my Dad…
Could you please tell me how to disable delete command if suppose where conditions is not specified in Delete ( For security Purpose)
One option is to use DELETE trigger and check for the number of records
If (select count(*) from table)=0
However it will not gaurantee when all rows are delete using the where clause.