SQL Validator

No structural error found (0 finding(s) reported).

How it works

• Tokenised the SQL, keeping literals, identifiers and comments opaque.
• Checked parenthesis depth and string/comment terminators.
• Classified the leading keyword of each top-level statement.

• Warnings do not make the statement invalid; only error-severity findings do.

Methodology

1. Tokenise the statement, treating strings, quoted identifiers and comments as opaque so their contents are never mis-read.
2. Track parenthesis depth and quote/comment terminators, naming each structural problem with an offset.
3. Identify the leading command keyword of every top-level statement and flag an unrecognised one as a warning.

Usage

1. Paste a SQL statement or script.
2. Choose the dialect whose lexical rules should apply.
3. Run the validator and read the named findings; a clean result means no structural problem was found.

Examples

These are examples, not current values: they use fixed inputs, while the interactive tool computes live results in your browser.

A valid SELECT

{
  "text": "select id, name from users where id = 1;",
  "dialect": "standard"
}

Unbalanced parenthesis

{
  "text": "select count(*) from users where (id = 1;",
  "dialect": "postgresql"
}

MySQL backtick identifier

{
  "text": "select `full name` from `users`;",
  "dialect": "mysql"
}

Limitations

Structural checks, not a schema check

A validator can see delimiters, quotes and comments; it cannot know your tables or columns. Treat a clean result as one gate among several before you run anything against a real database.

Dialects change the rules

MySQL accepts backtick identifiers and backslash escapes; T-SQL uses square brackets; PostgreSQL adds dollar-quoted strings. Choosing the right dialect keeps the validation honest.