DevUtilKit SQL Runner FAQ

Some questions repeat across teams: why a query is rejected, why pagination appears unstable, or how exports are bounded. This page consolidates those answers with direct links to deeper documentation.

Why was my query rejected?

Most rejections come from non-read-only patterns, semicolons, multi-statement text, or unsupported syntax assumptions.

Check Query Safety docs and simplify to minimal SELECT first, then rebuild incrementally.

Why does page 2 look inconsistent?

Unstable ordering usually means missing deterministic ORDER BY.

Add clear ordering on unique or near-unique keys before comparing pages.

How should I share results?

Prefer bounded exports with only required fields. Include query context and timestamp in notes for reproducibility.

For ongoing reporting, transition to a governed analytics flow instead of repeated manual exports.

What data is stored?

Tool behavior varies by feature class. Browser tools remain local; SQL Runner uses backend execution with bounded logging controls.

Read Data Handling and Privacy pages for full disclosure scope.

Where can I get help?

Use support@devutilkit.com or the Contact page with route + input + expected vs observed behavior details.

Structured reports reduce turnaround time and improve fix quality.

Escalation Rules For Complex Investigations

SQL Runner is ideal for fast read-only verification, but some investigations require escalation. Move to a full database client when you need schema introspection, long-running analytical scans, controlled write operations, or advanced plan analysis. Defining escalation rules up front prevents wasted cycles trying to force complex workloads through a bounded utility surface that is intentionally optimized for short diagnostic loops.

During escalation, preserve continuity by sharing the exact SQL Runner artifacts that motivated deeper investigation. Include query text, timestamp window, expected behavior, and observed output. This context helps database specialists continue from validated evidence rather than restarting discovery. Teams that combine lightweight first checks with disciplined escalation usually resolve incidents faster and generate clearer post-incident learning records.