Check the SQL That Will Run

The SQL your agent writes is only part of what runs. The Node Type wraps it in the DDL and DML that actually reach your warehouse. Check both, in order: compile first, then run against your development schema.

Open the Node

Double-click the Node in the graph, or right-click it and choose Edit. The actions on this page sit in the toolbar above the bottom pane. The pane has two tabs: Code for SQL and run output, and Preview for sample rows. For a tour of the editor, see The SQL Node Editor.

Check the Problems Panel

Select Problems in the left rail. It lists problems across the Workspace. When there are none, it reads No problems have been detected in the workspace.

An invalid reserved annotation, such as @materializationType("TABLE"), appears here, is underlined in the editor, and blocks a deploy. An annotation name the Node Type doesn't declare appears as a warning. It doesn't block a deploy, but the annotation has no effect. Ask your agent to clear every problem before you go further. coa validate reports the same annotation issues from the terminal.

Compile Without Running

These actions send SQL to your warehouse to compile it without executing it.

Action	What it compiles
Validate Select	A SELECT built from the Node's SQL.
Validate Create	Every statement in the Node Type's Create template, the DDL. Find it in the menu on Create.
Validate Run	Every statement in the Node Type's Run template, the DML. Find it in the menu on Run.

On Snowflake and Databricks, Coalesce wraps each statement in EXPLAIN, so nothing is created, changed, or loaded.

BigQuery in Coalesce Desktop

On BigQuery in Coalesce Desktop, Validate Create and Validate Run currently run their statements instead of a dry run. Validate Create creates the table, and Validate Run loads it. Use them only against a development dataset. To read the rendered SQL without contacting BigQuery, ask your agent to run coa create --dry-run --verbose or coa run --dry-run --verbose instead. See Check From the CLI.

The Code tab shows each rendered statement and whether it compiled. Read it for:

• Target names. The database and schema should be your development schema, never production.
• Materialization. A CREATE TABLE or CREATE VIEW that matches what you asked for.
• Load strategy. A full rebuild, an insert, or a MERGE, and the keys the MERGE matches on.
• Every column. Names, types, and order in the DDL. A column typed UNKNOWN on Mapping needs a cast in the SQL.

If a Node Type has no Create or Run template, that button doesn't appear.

Run Against Your Development Schema

When the compiled SQL looks right, run it for real:

1. Select Create to apply the DDL.
2. Select Run to load data.

Both run directly from your machine against the Storage Locations your Workspace maps to, with the credentials in your coa profile. The Code tab lists each statement as it runs, with its status and any error.

Open Preview to see sample rows from the result. If they don't load on their own, select Load Preview. See Auto-Preview.

Check:

• Row count. Does it match what your agent reported, and what you expect from the source?
• Duplicates. Does each business key appear once, or once per version for a Type 2 dimension?
• Nulls. Are key and join columns populated?
• Tests. If the Node has tests, did they pass?

Check From the CLI

Your agent can check from the terminal and paste the output into its report:

Command	What it does
coa validate	Validates the Workspace files and scans for problems such as broken column references, duplicate names, and circular dependencies.
coa create --include '{ STG_ORDERS }' --dry-run --verbose	Renders the Create SQL on your machine and prints it. It doesn't contact your warehouse, so it won't catch compile errors.
coa run --include '{ STG_ORDERS }' --dry-run --verbose	The same for the Run SQL.
coa create --include '{ STG_ORDERS }'	Applies the DDL in your development schema.
coa run --include '{ STG_ORDERS }'	Loads data in your development schema.

See coa Commands for every option.

What's Next?

• Check Lineage and Impact
• The SQL Node Editor
• The Node Editor for how each action behaves on YAML Nodes