Refuse UPDATE/DELETE with no WHERE

Catch, warn about, or block broad UPDATE and DELETE statements before a tiny omission becomes a very long afternoon.

Before a batch runs, SQLly checks for UPDATE and DELETE statements without a WHERE clause. It masks strings and comments first, so a keyword inside a literal does not create a false alarm. Connection policy can warn about these statements or block them outright.

DELETE FROM orders  → ⚠ affects every row

Identity-column INSERTs on SQL Server

An INSERT that supplies a value for an identity column - named in the column list, or positional with no column list - gets a live warning squiggle when no SET IDENTITY_INSERT <table> ON precedes it in the script, explaining exactly which column is the identity and what to run. The check tracks ON/OFF switches per table through the script (an earlier ON silences it, a later OFF re-arms it), matches schema-qualified and bracketed spellings case-insensitively, and stays quiet on engines without the switch, on unknown tables, and on DEFAULT VALUES inserts.

Fixing it with one click

You do not have to type the switch yourself. Right-click the underlined identity column and the editor's context menu offers Turn IDENTITY_INSERT ON for <table> around this INSERT - naming the table exactly as you spelled it in the statement. Choosing it writes the ON above the statement and the OFF below it, and the squiggle clears.

-- before: right-click SiteId
INSERT INTO HR.WorkSite (SiteId, Name) VALUES (1, 'Palms');

-- after
SET IDENTITY_INSERT HR.WorkSite ON;
INSERT INTO HR.WorkSite (SiteId, Name) VALUES (1, 'Palms');
SET IDENTITY_INSERT HR.WorkSite OFF;

The rewrite is deliberately narrow. It wraps only the statement you clicked in, leaving the rest of the script untouched; it matches that statement's indentation, so a nested INSERT keeps its shape; it adds the missing semicolon if the statement did not have one, so the trailing OFF cannot run into it; and your caret stays on the column you right-clicked. Because each pair is scoped to a single statement, you can apply it to several inserts in the same script and each one turns the switch on and off around itself - which is also what SQL Server wants, since only one table per session may have IDENTITY_INSERT on at a time.