## TL;DR
Snowflake cant find the object because the fully qualified name is wrong: wrong database, wrong schema, wrong case, or the object was never created. Fully qualify as `DATABASE.SCHEMA.OBJECT`, check the session's current database and schema, and remember unquoted identifiers are uppercased.

```text
snowflake SQL compilation error: Object does not exist
```

## Use this when
- A Snowflake query fails with object does not exist
- An agent queries with a partial or wrong name
- The object exists but the query cant see it

## Not for this skill when
- The error is about privileges (thats a grant problem)
- The warehouse is suspended or too small (thats compute)
- The SQL syntax itself is invalid (thats parsing)

## Steps

1. Check what database and schema your session is using:

```sql
SELECT CURRENT_DATABASE(), CURRENT_SCHEMA();
```
Expected output: the session context. An unqualified `orders` resolves here; if the table lives elsewhere, this is the mismatch.

2. Fully qualify the object name:

```sql
SELECT * FROM ANALYTICS.PUBLIC.ORDERS LIMIT 10;
```
Expected output: the query works, or the error persists (which proves the object truly doesnt exist under that name).

3. Verify the object exists with the exact case:

```sql
SHOW TABLES LIKE 'ORDERS' IN SCHEMA ANALYTICS.PUBLIC;
```
Expected output: the table listed with its exact name. Snowflake uppercases unquoted identifiers, so a table created as `"orders"` (quoted lowercase) is invisible to `ORDERS`.

4. If it was created quoted-lowercase, quote it everywhere or rename:

```sql
SELECT * FROM ANALYTICS.PUBLIC."orders" LIMIT 10;
```
Expected output: rows return. Better long-term: rename to an unquoted name so nobody has to remember the quotes.

## Variant phrasings

### object exists in the UI but not in the worksheet
The UI and worksheet use different roles or different database contexts. Check `CURRENT_ROLE()` too; a role without USAGE on the schema gets the same "does not exist" message.

### worked yesterday, fails today
Someone dropped/renamed the object, or the session context changed (a script that used to `USE DATABASE` first). Check both.

## Why it happens
Snowflake resolves names against the session's current database, schema, and role. Any of those being wrong produces "object does not exist" even when the object is real, and the message deliberately doesnt say which part is wrong (or whether it is a permission issue). Agents generate queries with bare table names and no `USE` statements, so context mismatches are their top cause.

## Edge cases
- Cloned databases: the object exists in the source but your session points at the clone, or vice versa.
- Reader accounts see only shared objects; the object may genuinely not exist in your account.
- Temporary tables vanish with the session; a temp table from yesterday's session is gone today.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tu7KWkWvD6iZOZcYUQvlTw