Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-08-06 17:36:53 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
bcquality/microsoft/knowledge/breaking-changes/obsolete-table-fields-instead-of-deleting-them.md
Jesper Schulz-Wedde 5706959e4a
Fix lifecycle compatibility guidance (#93) 
* Fix lifecycle compatibility guidance

Correct high-confidence Business Central guidance and samples for upgrade tags, collectible errors, trigger semantics, obsoletion, events, interfaces, API contracts, and test transactions.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: e05a43e7-6448-4d67-9c73-798523f5d945

* Address guidance review findings

Gate SecretText guidance to BC23 and clarify that the collectible-error sample intentionally emits a message-only blocking aggregate.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: e05a43e7-6448-4d67-9c73-798523f5d945

---------

Co-authored-by: Jesper Schulz-Wedde <jesper.schulzwedde@microsoft.com>
2026-07-14 11:26:16 +02:00

1.9 KiB
Raw Blame History

bc-version domain keywords technologies countries application-area
all
breaking-changes
table-field
obsoletestate
obsoletereason
obsoletetag
pending
removed
data-loss
al
w1
all

Obsolete published table fields instead of deleting or renumbering them

Description

A shipped table field carries both a source-level contract and persisted data. Renaming a field while retaining its ID is prohibited by AppSourceCop AS0005 and can break dependent extensions, but it is not inherently a drop-and-readd operation and should not be described as automatic data loss. Deleting the field or replacing it under a different ID is the data-loss risk: the old field storage is no longer represented unless data is migrated. The supported path is to keep the old field and obsolete it, add a replacement under a new ID, and migrate values before later removal.

Best Practice

Add the replacement field under a new ID, then mark the old field ObsoleteState = Pending with an ObsoleteReason that names the replacement and an ObsoleteTag recording the obsoletion version. Keep the old field readable so an upgrade codeunit can copy its data during the deprecation window. Move it to ObsoleteState = Removed only in a later release, after the window has passed and data has migrated.

See sample: obsolete-table-fields-instead-of-deleting-them.good.al.

Anti Pattern

Renaming published Email to Contact Email with the same ID violates the compatibility contract and AS0005, even though the retained ID does not itself imply a fresh empty column. Deleting Email or moving the replacement to another ID without migration additionally risks losing its stored values. Detection: a previously shipped field removed, renumbered, or renamed with no retained Pending field and migration path.

See sample: obsolete-table-fields-instead-of-deleting-them.bad.al.