mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-08-06 17:36:53 +01:00
0c2a0ceb82
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 95c06ad8-377d-4faa-8d07-06300b1c81ec
26 lines
1.2 KiB
Markdown
26 lines
1.2 KiB
Markdown
---
|
|
bc-version: [all]
|
|
domain: upgrade
|
|
keywords: [on-check-preconditions, on-validate-upgrade, on-upgrade, read-only-check, data-migration]
|
|
technologies: [al]
|
|
countries: [w1]
|
|
application-area: [all]
|
|
---
|
|
|
|
# Upgrade check triggers do not migrate data
|
|
|
|
## Description
|
|
|
|
`OnCheckPreconditionsPerCompany`/`PerDatabase` run before the upgrade to verify that it can start. `OnValidateUpgradePerCompany`/`PerDatabase` run after upgrade logic to verify that it succeeded. Treat both phases as read-only checks. The `OnUpgradePerCompany`/`PerDatabase` phase is where the platform expects actual data transformation.
|
|
|
|
## Best Practice
|
|
|
|
Have check triggers call query-only helpers that raise an error when an invariant fails. Put every `Insert`, `Modify`, `Delete`, `Rename`, `DataTransfer`, and other migration write behind helpers called from the matching `OnUpgrade...` trigger.
|
|
|
|
See sample: `check-only-triggers-do-not-migrate-data.good.al`.
|
|
|
|
## Anti Pattern
|
|
|
|
Repairing data in `OnCheckPreconditions...` or finishing migration in `OnValidateUpgrade...`. Those writes blur the phase contract and make a check alter the state it is supposed to assess.
|
|
|
|
See sample: `check-only-triggers-do-not-migrate-data.bad.al`.
|