## TL;DR
Drop or rename the leftover derived table in the scratch schema, then trigger a full PDT rebuild, because the regenerator refuses to overwrite a table it did not create cleanly. A failed earlier build, a manual table created in the scratch schema, or a changed persist key leaves an orphan that blocks every later build. Removing the orphan and rebuilding restores the dashboard data.

```text
table already exists
```

## Use this when
- The PDT regenerator log shows an already exists error for a derived table.
- Dashboards on the explore went empty after a failed or interrupted PDT build.
- A datagroup trigger fired but the PDT timestamp never advances.

## Not for this skill when
- The PDT builds on schedule but the numbers are wrong. Debug the derived table SQL instead.
- The scratch schema itself is missing or the connection lacks write rights. Fix connection permissions first.

## Steps
1. Open the Admin PDT panel or the regenerator log and identify the exact table name in the already exists error. Verify: the named table sits in the connection scratch schema
2. Check whether the table is a live PDT in use or an orphan from a failed build by comparing its name and creation time with the PDT list. Verify: the table is not the current healthy build for another view
3. Drop the orphan table from the scratch schema, or rename it aside if your team keeps build artifacts for inspection. Verify: the scratch schema no longer contains a table with the colliding name
4. Trigger a rebuild of the PDT from the explore or the admin controls and watch the build complete. Verify: the regenerator log shows a successful build with a new timestamp
5. Run the explore that depends on the PDT and confirm it reads the new table. Verify: the generated SQL references the rebuilt PDT and returns current rows
6. Open the affected dashboard and confirm the previously empty tiles render, then review the datagroup so the next scheduled build proceeds normally. Verify: tiles show data and the PDT last built time is recent

## Why it happens
PDT creation is intentionally defensive. Looker will not silently overwrite a table it cannot prove it owns, because the scratch schema can be shared and a wrong drop could destroy another process table. The cost of that safety is that one orphaned build blocks the chain until an operator clears it. Keeping humans out of the scratch schema and letting interrupted builds be cleaned promptly avoids repeat blocks.

Looker builds persistent derived tables in the connection scratch schema under generated names that encode the model, view and persist conditions. If a build is interrupted, or someone creates a table with a colliding name, the next build can fail on creation because the table already exists. Dependent explores then return no data or error, so the dashboard looks empty even though the source data is fine.

Field notes for Looker specifically. The Admin area holds the diagnostic pages that matter here, System Activity for query history and runtimes, the PDT activity page for derived table builds, and the Content Validator under the content management tools. Keep the browser on the same Looker version as the instance when testing, because explore behaviour and error wording shift slightly between monthly releases. Screenshots from viewers are worth collecting with the exact load time, since Looker support and your own history search both work far better from a timestamp than from a description of slowness.

A practical habit for Looker teams is to keep one test user per permission tier and to test every model change as the most restricted tier, not as an admin. Admins bypass access filters, see every field, and hit warm caches, so admin testing systematically hides the failures viewers get. Pair that with a standing explore that lists the twenty slowest tiles across the instance each week, and most dashboard incidents become follow ups on a report the team already reads, instead of surprises reported by executives in a meeting.
## Variants and edge cases
### Looker PDT table already exists rebuild failed
The direct phrasing from the regenerator error.
### Looker derived table build blocked orphan table scratch schema
The orphan-focused variant naming the scratch schema.
### Looker dashboard empty PDT not building fix
The viewer-symptom phrasing that starts from the empty dashboard.

## Provenance

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