Catalog and lineage errors

Use this page for errors that stop the Paradime Catalog from building. The Catalog and lineage are produced by the same build, so when a build fails the workspace has neither until it succeeds. Other workspaces are unaffected.

dbt found two relations in your warehouse with similar database identifiers

Compilation Error
  dbt found two relations in your warehouse with similar database identifiers. dbt
  is unable to determine which of these relations was created by the model "source.my_project.src.my_table".
  In order for dbt to correctly generate the catalog, one of the following relations must be deleted or renamed:

   - SRC.MY_TABLE
   - SRC.My_Table

The Catalog is built by dbt docs generate. That command queries your warehouse’s information schema for every relation in the schemas your project uses, then matches each relation back to a node in your dbt™ project. It lowercases both sides to compare them. Your warehouse holds two physical relations whose names differ only by letter case. Both lowercase to the same name, so dbt cannot tell which one the node refers to, and it stops before writing the catalog. On warehouses that uppercase unquoted identifiers, such as Snowflake, this happens when one relation is created unquoted (MY_TABLE, stored uppercase) and another is created quoted ("My_Table", stored as written). A quoted CREATE TABLE, an ingestion tool that quotes identifiers, or a shared database you do not control are the usual origins. Three things are worth knowing before you start looking:

The duplicate is in your warehouse, not in your dbt™ project. Searching your repository or comparing branches finds only one model or source definition, which is correct. That single definition is the one dbt cannot match to a relation.
dbt compile cannot detect this. Compile parses the project and renders Jinja; it never queries the information schema. A green compile run tells you nothing about whether the Catalog will build.
Setting quoting in sources.yml does not fix it. Quoting controls how dbt™ writes the identifier when it queries your data. The catalog matcher lowercases regardless, so both relations still collide.

To fix it:

List both relations. On Snowflake:

select table_catalog, table_schema, table_name, created, last_altered, row_count
from <database>.information_schema.tables
where table_schema = 'SRC'
  and upper(table_name) = 'MY_TABLE';

Compare created, last_altered and row_count across the two rows to work out which relation your pipeline actually writes to.
Drop or rename the other one. The mixed-case relation must be quoted to address it:
drop table <database>.SRC."My_Table";
Rebuild the Catalog. You can wait for the overnight refresh, run paradime catalog refresh from your terminal, or add the Refresh Paradime Catalog command to a Bolt schedule.

If an ingestion job or an external share recreates the relation, the error returns on the next load. Track down what created the quoted relation, or the Catalog breaks again. Where you cannot drop or rename either relation, for example in a Snowflake Marketplace database that another account owns, there is no project-side workaround. This is a known dbt™ Core limitation, tracked in dbt-core issue #8253. Contact support@paradime.io and we will help you work through the options.

Support

Troubleshooting

Security & Privacy

Catalog and lineage errors

dbt found two relations in your warehouse with similar database identifiers

​dbt found two relations in your warehouse with similar database identifiers

dbt found two relations in your warehouse with similar database identifiers