topic Re: Fabric dbt job fails but same code works on my own laptop in Data Engineering

Fabric dbt job fails but same code works on my own laptop

Reponen — Thu, 30 Apr 2026 12:22:32 GMT

Hi,

I have faced few proplems.

I have test that checks if key is null.

On my ownlaptop it gives pass but in fabric enviroment it gives failed

Also somehow dbt in fabric changes timestamp2(6) -> (7) and fails.

Is there way to see combiled dbt code in fabric to pinpoint proplem?

-V

Re: Fabric dbt job fails but same code works on my own laptop

Lodha_Jaydeep — Thu, 30 Apr 2026 13:43:25 GMT

Hi @Reponen,

Thanks for reaching, will happy to assist.

Yes, you should be able to inspect the compiled dbt SQL, but the exact location depends on how the Fabric dbt job is being run.

In a normal dbt project, compiled SQL is generated under target/compiled/

and SQL is often under target/compiled/

So first check whether the Fabric job output/artifacts expose the target older. The useful files are usually below:

target/compiled/<project_name>/models/...
target/run/<project_name>/models/...
target/manifest.json
target/run_results.json

If fabric do not expose directly you can add debugger step before/after dbt run or dbt test to list or copy target foler to lakehouse for example,

dbt compile ->Inspect->target/compiled

For troubleshooting please check dbt version in local and fabric

dbt --version

dbt debug

dbt compile

The timestamp2(6) to timestamp2(7) difference suggests the Fabric environment may be using a different adapter, connector, SQL dialect behavior, or package/dbt version than your laptop. Make sure the dbt version and adapter version match locally and in Fabric.

Please consdier this as an accepetd solution if it helps, or give some kudos.

Re: Fabric dbt job fails but same code works on my own laptop

Olufemi7 — Thu, 30 Apr 2026 13:43:30 GMT

Hello @Reponen,

You can see this in Fabric because it’s not the same engine as your local dbt run, so small differences show up.
The null test usually means the data isn’t exactly the same in Fabric (timing, duplicates, actual nulls). The datetime2(6) → (7) change is also normal — Fabric can use higher precision, which then breaks strict tests.
You can check what dbt actually ran: open the job run, go to Artifacts / Logs, and look at manifest.json or the target/compiled output.
What normally helps is compiling locally (dbt compile), then running the compiled SQL in Fabric to see where it differs. If it’s the timestamp, just cast it explicitly, e.g. CAST(column AS DATETIME2(6))

Reference: datetime2 (Transact-SQL)

Re: Fabric dbt job fails but same code works on my own laptop

v-ssriganesh — Mon, 04 May 2026 04:09:13 GMT

Hi @Reponen,

Thank you for posting your query in the Microsoft Fabric Community Forum, and thanks to @Olufemi7 & @Lodha_Jaydeep for sharing valuable insights.

Could you please confirm if your query has been resolved by the provided solutions? This would be helpful for other members who may encounter similar issues.

Thank you for being part of the Microsoft Fabric Community.

Re: Fabric dbt job fails but same code works on my own laptop

v-ssriganesh — Thu, 07 May 2026 04:24:50 GMT

Hello @Reponen,

We hope you're doing well. Could you please confirm whether your issue has been resolved or if you're still facing challenges? Your update will be valuable to the community and may assist others with similar concerns.

Thank you.