Forum Discussion
Fabric SQL database column name changes randomly
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!
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
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!