Poking around production without holding your breath

The reason I reach for this on a production box isn't discipline. It's that the tool can't really do anything else.

SELECT or nothing

Everything SqlPeek sends has to be a single SELECT (or WITH ... SELECT). The guard checks the statement before it reaches the server, so:

• INSERT, UPDATE, DELETE, MERGE — refused
• DROP, ALTER, CREATE and the rest of DDL — refused
• SELECT ... INTO — refused
• stacked statements separated by ; — refused
• sp_ / xp_ procedure calls — refused

Invoke-SqlPeekQuery -AllowWrite is the one explicit override, and it isn't subtle — you have to type it out.

The check is about the statement, not the raw text. Quoted strings are excluded, so a predicate like Name LIKE '%update%' is a search, not a rejection.

The rest of the construction

A few other things fall out of the same design:

• identifiers you pass to -Table, -Columns and -OrderBy are validated against an allow-list and bracket-quoted — never concatenated into the SQL string
• values you pass with -WhereParam (or -Param on pkq) go to the server as SqlParameters, so an apostrophe in a name is a character, not a syntax error
• pkon -ReadOnly sets ApplicationIntent=ReadOnly on the connection

There's no change tracking, no relationship graph, and no way to write an object back. It reads, and that's the whole surface.

Poking around someone's production database is about as eventful as ls.

That line is from the README, and it's the honest pitch. SqlPeek isn't safer than SSMS because I'm careful with it — it's safer because the destructive options aren't wired up. On a box where a stray UPDATE ruins an afternoon, that's worth something.

Source and install: github.com/jackneff/SqlPeek.