Dynamics Community Forum Thread Details

Environment

Dynamics 365 Business Central online (SaaS), version 28.1

Migration path: NAV 2009 R2 → NAV 2013 → NAV 2018 → BC 2025 on-premises → BC online (SaaS) → v27 (now 28.1)

The system went live about 4 months ago, and since go-live all other modules and processes are working correctly — only the Fixed Assets module is affected by this issue

A Microsoft support case is open (currently with the BC APAC team)

The problem

After the migration, table 5600 "Fixed Asset" contains about 1,038 records (out of ~23,320) whose primary key ("No." field) contains invalid/hidden bytes at the SQL level. The keys look normal on screen but do not match when looked up by primary key. Importantly, every other module migrated cleanly and has been running without issue for the last 4 months — this corruption is isolated to Fixed Assets.

Symptoms:

The Fixed Asset list page won't open: "The view cannot be displayed due to invalid record bookmarks. Ensure that the primary key of the records is unique."

Opening some cards: "The record that you tried to open is not available. The page will close or show the next record."

After normalization (uppercase + trim), ~1,038 "No." values look like duplicates — e.g. two KDFF7857, two CM003LHFF2166.

How I diagnosed it (with AL)

Looping the table with FindSet returns each record fine, but calling Rec.Get("No.") with the displayed value returns nothing — and where it does return a row, its SystemId differs from the looped record. So the on-screen key ≠ the key stored in SQL.

Cleaning in AL (UpperCase(DelChr("No.",'<>',' '))) shows no difference — reads come back already normalized, so the bad bytes are only visible at the database layer, not to AL.

The same corruption appears in a sandbox copied from Production, so it's in the data, not a one-off.

Everything I have tried — all fail

Rename / Delete / Modify by key → operations hit the wrong row or affect 0 rows.

Delete by SystemId (GetBySystemId then Delete) → fails.

Full rebuild: copy all rows to a staging table (a read-only FindSet scan can read the corrupt rows), then DeleteAll on 5600, then re-insert clean → fails at DeleteAll with "Sorry, we just updated this page. Reopen it, and try again." (optimistic concurrency — the row-by-row delete matches 0 rows on the phantom records).

Ran the rebuild as a background Job Queue task → same failure.

Uninstalled ALL non-Microsoft extensions and retried → same failure (so it is not custom code or an event subscriber degrading DeleteAll).

New Rec.Truncate method (2025 wave 2) → not usable here. Per Microsoft's own documentation, Truncate does not support tables with OnDelete triggers/event subscriptions (both 5600 and 5612 have OnDelete triggers) or tables with media fields (5600 has the "Image" Media field). So it errors / is unavailable on these tables.

So every application-layer method is blocked: Delete, Rename, DeleteAll, and Truncate.

What I think the cause is

NAV 2009 R2 stored Code fields differently (space padding, older SQL collation). I suspect those "No." values carried trailing spaces / control characters / collation-specific bytes that were valid in NAV 2009 R2, survived each upgrade step, and only became invalid primary keys once the data reached BC online (Azure SQL). The source databases are decommissioned, so I can't check the original collation.

My questions to the community

Has anyone hit primary-key corruption like this after a long NAV upgrade chain into BC online? What was the root cause and how was it fixed?

Is there any supported AL or admin technique to delete or repair rows that are unreachable by primary key, given that DeleteAll and Truncate are both unavailable on these tables?

For those who raised it with Microsoft — did support perform a database-level cleanup of the rows, or did they have you rebuild into a new company? Roughly how long did it take?

Best practice to prevent this on a future migration — e.g. cleaning the source "No." values (uppercase / trim / strip control + non-ASCII characters) before the replication/upgrade step? At which stage should the cleaning happen?

I have the full list of 1,038 affected "No." values and a temporary read-only "Safe View" page in place so users can still see the ~22,282 healthy assets in the meantime.Any guidance appreciated — thank you!