FetchXML ↔ SQL Converter

Translate a limited FetchXML subset into readable generic SQL, or a simple single-table SQL SELECT into FetchXML. The local, best-effort converter shows validation and warnings because joins, nested logic, aggregates, functions, aliases, operators, row limits, and dialect details may be unsupported or lossy.

How to Use the FetchXML ↔ SQL Converter

Use the converter as a reading and drafting aid, then verify the result against FetchXML semantics and your SQL dialect.

  1. Choose direction with the swap control: FetchXML to SQL or SQL to FetchXML.
  2. Paste FetchXML or a simple SELECT into the source editor.
  3. Select Convert and read the validation message plus every warning.
  4. Compare source and result side by side—especially filters, joins, ordering, distinct, and limits.
  5. Copy or download the draft, then revise and test it in an authorized non-production environment.

Conversion method

FetchXML parsing is regex-based: top-level attributes, a flat filter, simple link-entities, orders, and distinct become generic SQL. SQL parsing recognizes one SELECT … FROM plus a limited WHERE/ORDER BY subset, then emits a FetchXML skeleton via the same builder model used elsewhere in these tools.

Example

A FetchXML entity account with attribute name often becomes SELECT name FROM account. Going the other way, SELECT name FROM account WHERE statecode = '0' can produce a fetch with an eq condition on statecode—still subject to warnings about approximation.

Output meaning

  • Warnings are part of the product—ignore them at your risk.
  • Link-entities may appear as INNER JOIN or LEFT JOIN drafts; relationship direction and aliases need human review.
  • Generated SQL is intentionally dialect-neutral commentary in places (especially limits).

Limitations to expect

  • Mixed AND/OR and nested filters are flattened or unsupported.
  • SQL JOINs, subqueries, functions, quoted identifiers, and comments are outside the SQL→FetchXML parser.
  • Neither output is guaranteed safe to run against production data.

Privacy note

Conversion runs entirely in the browser. Strip credentials, tokens, and confidential literals before pasting queries into tickets or chats.

FAQ

Is either direction production-ready as-is?

No. Output is an approximate draft for reading and review. Check identifiers, data types, quoting, joins, operators, row limits, security, and the target system's dialect before use.

What SQL can become FetchXML?

A simple single-table SELECT with optional DISTINCT, a basic WHERE whose conditions share one logical type (AND or OR), and ORDER BY. SELECT *, mixed AND/OR, JOINs, subqueries, functions, comments, and aliases are unsupported or lossy.

What is often lost converting FetchXML to SQL?

Aggregates, formatted values, nested filters/links, many Dataverse-specific operators, and dialect-specific limits may be omitted or approximated. Simple attributes, flat filters, orders, distinct, and basic link-entities map best—read every warning.

How are FetchXML operators mapped into SQL?

Common operators map to familiar SQL forms (for example eq → =, like → LIKE, null → IS NULL, begins-with/contains/ends-with → LIKE patterns, in → IN lists). Unrecognized operators may appear as a literal passthrough in the draft.

What happens to FetchXML count/paging in SQL?

When a count is detected, the SQL draft adds a comment reminding you to apply TOP, LIMIT, or OFFSET-FETCH in your dialect. It does not invent a portable row-limit clause for every engine.

Does Convert execute either query?

No. Conversion is a local text transformation with validation messages and warnings. It does not open a database connection or call Dataverse.

Why do mixed AND/OR conditions look wrong?

The parsers flatten to a single logical joiner. Nested filter precedence and mixed AND/OR trees are not preserved—rewrite those sections manually after conversion.