## TL;DR

The three-part name catalog.schema.table does not resolve. Check your profile's catalog and schema, confirm the upstream model was built in this catalog, and watch for Unity Catalog vs hive_metastore mismatches. Build upstream first with dbt build --select +model.

## Error

```text
Databricks table or view not found in dbt run
```

## Steps

1. Copy the fully qualified name from the error and compare it to your profile's catalog and schema settings.
   Expected: You see whether dbt aimed at the right catalog, often the bug is hive_metastore vs your Unity Catalog name.

2. In Databricks, browse the catalog to confirm the schema exists and check whether the table is actually there.
   Expected: You confirm the table is missing, or you find it under a different catalog.

3. If it is a dbt model, run dbt ls --select +the_model to see the upstream chain, then dbt build --select +the_model to materialize it.
   Expected: Upstream models build into the expected catalog and schema.

4. If the catalog was wrong, fix profiles.yml (or the dbt Cloud credential) and re-run.
   Expected: The model resolves the table and builds.

## When to use

- Databricks reports table or view not found during dbt run
- profile catalog does not match where tables were built
- switching between Unity Catalog and hive_metastore

## When not to use

- permission denied on an existing table (that is grants)
- cluster fails to start (infrastructure, not naming)
- the table exists but the query logic is wrong

## Tool compatibility

- dbt-databricks adapter; catalog and schema come from the profile or model config
- Databricks catalog explorer to verify real object locations
- dbt build --select +model materializes upstream first

## Variant phrasings

### table not found only for incremental models
Incremental models read their own target table on rerun. If the first build never completed, the target does not exist; run a full-refresh once.

### not found on a source
The source definition's catalog or schema is wrong. Fix sources.yml, not the profile.

## Why it happens

Databricks names are three-part and Unity Catalog made the catalog part load-bearing. dbt builds the name from profile plus config, so a stale catalog in the profile or an unbuilt upstream model both surface as not found.

## Edge cases

- Delta table names are case-sensitive in some contexts; match the case dbt generates.
- If another team drops and recreates the table, dbt's cached relation info can lag; a full-refresh rebuilds cleanly.

## Provenance

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