The task
Scenario. An analyst needs a query against the `reporting` schema listing every customer and their orders, but doesn't know the exact table or column names going in. Someone else needs to know which status codes can actually update a record before writing the `WHERE` clause. Both are one failed query away from a wrong guess at a column name, or worse, a query that runs clean against the wrong field and returns a plausible-looking wrong answer.
The ask
- The tables in the schema that relate to what you need, matched on what they contain rather than a name you're guessing at
- Every column on those tables with its exact name, data type, and any description on record
- A query written against those confirmed names, with any column that doesn't exist flagged before you run it
Hero prompt
Before I write this query, show me the tables and columns in the `reporting` schema that relate to customers and their orders, with their real names and types.
Step by step
-
Find the tables the question is about.
Find the tables in the <schema> schema that relate to <what you need — e.g. customers and their orders>. Match on a description, not just names I'm guessing at.
-
Pull their real columns, types, and descriptions.
For those tables, list every column with its exact name, data type, and any description on record, so I write against what's actually there.
-
Write the query against the confirmed names.
Using only the columns you just confirmed, write the query for <what you're trying to answer>, and flag any column I reference that doesn't exist in the schema you pulled.
What you'll give it
Required context
- The schema or table name, or a description close enough to find it
- What you're trying to answer or build with the query
Optional context
- A first-draft query you already have, so it can check it against the real schema instead of building blind
- Any known naming quirks in the source (e.g. non-English column names, legacy naming conventions)
What Atlan creates
Outputs
- The confirmed table and column names, types, and descriptions for the schema in question
- A query written against those confirmed names, ready to run
Summary. The query runs against real columns on the first attempt, instead of failing on a guessed name or, worse, running clean against the wrong one.
Read-only. Nothing in Atlan is written or updated; this only pulls schema context ahead of writing SQL elsewhere.
Follow-up prompts
Keep going once the first answer lands.
Check for governed definitions
Check if any of these columns already have a governed definition before I use them in a report.
Widen it to the whole query
Do the same check across every table this report joins, not just the first one.
Catch anything being retired
Flag if any of these columns are deprecated or scheduled for removal.
Tips & troubleshooting
The failure mode that costs you time isn't the query that errors out, it's the one that runs clean against a column that means something slightly different than you assumed.
- Match the client to the work. Run this in whatever client you're about to write the SQL in, so the schema context lands in the same session as the query.
- Automate or chain it. Chain this ahead of every ad-hoc query against an unfamiliar schema, not just the first time you touch it. Naming conventions vary enough between schemas that "I checked it last month" isn't the same as checking it now.
- Confirm what it used. This is read-only, so nothing changes — but when you paste the query back in afterward, ask it to confirm every column you reference actually exists in the schema it pulled.