Database Build Failure Due to Data Type Mismatch from Snowflake Bridge

You may encounter a database or workflow failure when building a table from a Snowflake Bridge if the field data types returned from Snowflake do not match the types configured in Amperity. This article explains why this happens and how to resolve it.

 

What You May See

A workflow or database generation step may fail with an error similar to:

Failure binding configured inputs to resolved state: type mismatches for fields …

This indicates that at least one column in the bridged table is returning a different data type than what Amperity expects.

Why This Happens

Amperity enforces strict schema consistency for Snowflake Bridge tables. If Snowflake updates a view, or if a field’s precision/scale changes, Amperity does not automatically adjust the table definition. Instead, it blocks the build to prevent downstream data quality issues.

Typical causes include:

  • Snowflake field precision increasing (e.g., decimal(28,0) → decimal(38,0))
  • A field changing from decimal to float
  • Schema inference changes in Snowflake views

When this happens, Amperity detects a mismatch between:

  • Configured data type in Amperity
    and
  • Actual data type returned from Snowflake

This prevents the database from building.

How to Fix It

To resolve the error and allow the workflow to run successfully:

  1. Review the failing table fields listed in the error message.

  2. Ask your Snowflake team to update the source view or query so the fields are explicitly cast to the data types Amperity expects.

    For example, you may need casts such as:

    CAST(UNITS AS DECIMAL(28,0))
CAST(YR_PROPENSITY AS DECIMAL(38,2))
  3. Save the Snowflake view changes.
  4. Sync the Snowflake Bridge again in Amperity.
  5. Retry the workflow.

Once the Snowflake schema matches the configured Amperity schema, the table will build successfully and the workflow will complete normally.

 

Best Practice

Whenever Snowflake schemas change:

  • Ensure field precision, scale, and type remain aligned with Amperity configuration
    Use explicit casts instead of relying on inferred types
    Re-run database builds to confirm stability