Fabric SQL database column name changes randomly

[naveen_das]

Hi 

I have a Fabric SQL database and the system generated column name in the mirrored OneLake version of the tables keeps changing randomly. There a a Power BI semantic model that uses Direct Lake storage and that breaks with the error that the underlying column name has changed. 

- Is it a known issue or a bug, or am I missing something?

Appreciate your help.

Thanks

Naveen

[v-sdhruv]

Hi @naveen_das ,
Just wanted to check if you had the opportunity to review the suggestions provided?
If the response has addressed your query, please Accept it as a solution  so other members can easily find it.
Thank You

[v-sdhruv]

Hi @naveen_das ,
Just wanted to check if you had the opportunity to review the suggestions provided?
If the response has addressed your query, please Accept it as a solution  so other members can easily find it.
Thank You

[v-sdhruv]

Hi @naveen_das ,

 Yes,its always a good practice to define a unique clustered index explicitly in the SQL table.
The random column name changes in mirrored Fabric SQL tables in OneLake are linked to the automatic creation of system-generated columns, often used for internal tracking.
I hope your issue was resolved.
If any of the responses has addressed your query, please mark it as a solution so that other users can find it easily.
Thank you

[naveen_das]

Hi @burakkaragoz 

It turns out that if the underlying table in the Fabric database has a unique clustered index defined, the system column is not generated in the replicated copy in OneLake. This takes care of the schema drift we were observing with the Direct Lake storage mode Power BI semantic model.

Thanks

Naveen

[burakkaragoz · Accepted solution]

Hi @naveen_das ,

This issue is something several people have noticed when using Direct Lake and mirrored tables in Fabric. When mirroring is enabled, especially with auto-generated schemas, column names can sometimes shift because of metadata syncs or schema inference on the OneLake side.

This generally happens if:

• The source table's schema or metadata changes, even slightly (like case sensitivity or data type).
• The mirroring process re-checks schema during a refresh or sync.
• The mirrored table is recreated or rehydrated behind the scenes.

Here's what you can try for better stability:

• Define explicit column naming and indexes in your original SQL tables, rather than relying on auto-generated ones.
• In your semantic model, map columns explicitly instead of using auto-detection.
• Try to avoid renaming or altering columns in the source system after mirroring is set up.
• If stability is critical, use Lakehouse tables with defined schemas instead of mirrored ones.

Lastly, keep an eye out for any known bugs or updates from Microsoft regarding this behavior. It might be something under review or with a hotfix pending.

If this helped, feel free to mark as Accepted Solution so others can find the answer easily!

[burakkaragoz]

Hi @naveen_das ,

Yeah, this has been observed by a few folks working with Direct Lake and mirrored tables in Fabric. When using mirroring, especially with auto-generated schemas, column names can sometimes shift due to metadata sync issues or schema inference updates on the OneLake side.

This usually happens when:

• The source system changes column metadata (even minor ones like casing or type hints)
• The mirroring process re-evaluates schema during refresh or sync
• The table is recreated or rehydrated behind the scenes

What you can try:

• Use explicit column mapping in your semantic model instead of relying on auto-detection
• Avoid renaming or altering columns in the source system once mirroring is active
• If possible, use Lakehouse tables with defined schemas instead of mirrored ones for more stability

Also, worth checking if there’s an open issue or update from Microsoft on this — it might be a known behavior under review.

If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.