Fatal Actions Guard
There is always a risk of ruining data due to improper execution of UPDATE or DELETE statement without WHERE clause. In theory, of course, this should never happen as regular backups are supposed to be done, triggers and foreign keys are there to stop the deadly modification. But in reality additional protection can save you hours or work or even your job ;)
Fatal Actions Guard parses scripts executed in SSMS and checks for potentially dangerous statements like DELETE or UPDATE with missing WHERE clause or the usage of TRUNCATE statement which bypasses delete triggers. To get the overview of this feature go to SSMSBoost Settings -> Fatal Actions Guard:
It is possible to set an action if critical statements are found: should the execution be stopped or should the user be able to continue after confirming his/her intentions. You can also exclude particular tables from this check ("Exclude table names"). Moreover, you can add custom tokens that will cause the following actions if found:
Fatal Actions Guard parses scripts executed in SSMS and checks for potentially dangerous statements like DELETE or UPDATE with missing WHERE clause or the usage of TRUNCATE statement which bypasses delete triggers. To get the overview of this feature go to SSMSBoost Settings -> Fatal Actions Guard:
It is possible to set an action if critical statements are found: should the execution be stopped or should the user be able to continue after confirming his/her intentions. You can also exclude particular tables from this check ("Exclude table names"). Moreover, you can add custom tokens that will cause the following actions if found:
- "Ask" token - will force SSMSBoost to ask a user for execution confirmation. For example, if you add "#checklater" token in "ask" tokens list and start adding it to your scripts SSMSBoost will keep asking you for execution confirmation until you delete all these tokens. This can be practical if you are working on some script and want to mark critical places that should be verified.
- "Prohibit" token has a pretty similar logic but in case of triggering SSMSBoost will not allow you to run the script at all. You can add it to the script files that are not intended for blind execution. Sometimes system administrators collect frequently used commands in one script and it can be fatal if someone executes that file.
- "Magic unblocking" tokens allow you to disable execution guard for some particular script. For example, if you often use "full wipe" script to initialize your test database and use TRUNCATE there just add #breakingbad in settings and then add this token as a comment to your script to have the Execution Guard disabled that particular file.