Compliance Rules

Under Governance → Compliance Rules, DB Studio keeps the rules your organization's scripts must follow, such as "no DROP TABLE" or "every script names its ticket". Every script is checked against the active rules for its engine and environment, and the result is shown on the script in Migration Scripts.

How a Rule Is Checked

Severity

• Error: a failing rule fails the check. For a rule checked by a pattern, it also blocks approval of the script, and the editor says so under Severity.
• Warning and Info: shown with the result, never block.

Which Scripts a Rule Applies To

Engines and Environments limit a rule; with none chosen it applies to every engine or environment, and the editor says so. Each engine is offered once and named in words; SQL Server is one engine whether a connection or a rule calls it mssql or sqlserver. The engine is the type of the script's target connection, so a script without one skips rules limited to engines; the environment is the script's environment, or the environment approval is requested for. A rule that does not apply to a script is listed under its result with the reason, for example applies only to PostgreSQL, MariaDB; this script is for MySQL. Renaming an environment updates the rules that name it. Deleting one does not: the editor strikes that environment through, says it no longer exists, and saves the rule once it is removed. If the engines or the environments cannot be loaded, the editor says so where you would choose them, with Retry.

Writing a Pattern

Patterns are JavaScript regular expressions. Tick the flags you need: Ignore case, ^ and $ match each line, . matches line breaks and Unicode. Inline flags such as (?i) are not supported: tick Ignore case instead. A pattern that runs longer than 250 ms on a script is stopped, and its rule fails with that reason; anchor it or make it less ambiguous.

A new install has no rules; add the ones your organization needs.

Trying a Rule

In the rule editor, paste SQL under Test SQL and choose Test Rule. It runs the rule as written, without saving it or the SQL: you see whether the SQL passes or fails and the line the pattern matched. A pattern that does not compile, or runs too long, says why. Rules judged by the AI model are tried with the Compliance Check on the AI Agents page.

A Script's Result

Open a script in Migration Scripts. Its Compliance section shows whether it passes the pattern rules, each failing rule with its severity, the matched line and how to fix it (the rule's How to Fix), the rules the AI model judges, and the rules that do not apply with the reason.

While an error rule checked by a pattern fails, requesting approval for the script (or for a release that contains it), approving the script directly and signing an approval request are refused, and the message names the rules and scripts. Signing checks again, so a rule added after a request was made still counts. Fix the script, or have a Release Manager change, limit or turn off the rule, then try again.

The Compliance Check

On AI Agents → Compliance Check, paste a script, choose its engine and, if it matters, its environment. Rules checked by a pattern run without the AI model, so the check works even with no AI provider when all applicable rules are patterns. Rules judged by the AI model, and pattern hits of confirmed rules, go to the model. The result lists every rule checked, with evidence and how to fix it, and the rules that did not apply.

Who Can Do What