Skip to main content
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. The Lineage tab in the Code IDE runs on your development catalog. It is built the same way, from your branch and with your own Code IDE credentials, so the same errors can stop it for you alone while the Catalog builds fine.

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

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:
  1. List both relations. On Snowflake:
  2. Compare created, last_altered and row_count across the two rows to work out which relation your pipeline actually writes to.
  3. Drop or rename the other one. The mixed-case relation must be quoted to address it:
  4. 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.

​
000606 (57P03): No active warehouse selected in the current session

The build signed in to Snowflake, but its session has no warehouse to run queries on, so it stops at the first query that needs one. Snowflake takes the session’s warehouse from the Warehouse field of the connection, or from the Snowflake user’s default warehouse when the field is empty. If that warehouse does not exist, or the connection’s role has no USAGE privilege on it, Snowflake still opens the session and leaves the warehouse unset. A misspelled name, a warehouse that was renamed or dropped, and a role without the grant all end here. A wrong role fails earlier, at sign-in, with a different error. The Concurrency line near the top of the build log names the target, which tells you which connection the build used. The Catalog is built with the connection of your workspace’s default Bolt environment. Your development catalog is built with your own credentials on the Code IDE connection. To fix it:
  1. In Snowflake, list the warehouses the connection’s role can use:
  2. Open Settings > Environments and edit the connection the build used. Set Warehouse to a name from step 1, exactly as listed.
  3. Rebuild. The Catalog and your development catalog both rebuild overnight. To rebuild the Catalog now, run paradime catalog refresh or add the Refresh Paradime Catalog command to a Bolt schedule.

​
Required var ’…’ not found in config

A model calls var('my_var') without a default, and nothing set the variable for this build. Vars supplied to my_model = {} confirms that no variables were passed at all. The Catalog build and the development catalog behind the Code IDE Lineage tab both run dbt docs generate with no --vars, and that command compiles every model in your project. Your Bolt runs can stay green at the same time: a command that sets the variable with --vars, or selects only some models with --select, never compiles a model that needs it without a value. To fix it:
  1. Give the variable a default in dbt_project.yml:
    Values passed with --vars on the command line take precedence over this default, so Bolt commands that set the variable keep their value. You can also set the default where the model reads it: {{ var('my_var', 'my_default_value') }}.
  2. 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.