Integer to big integer field change
Integer to big integer field change
A field can change from integer to big integer while keeping existing rows, aimed at entries that run out of numbers. The compiler and AppSourceCop warn about implicit conversions and overflow, but the change is allowed without copying data.
Area: Developer tools. Status: GA. Developer relevance: high. Airtime: 6 min across 1 video, demoed.
Status evidence
- Nothing said about status; launch event convention: generally available unless stated otherwise.
Where they talk about it
- What's new in AL and Tools: 10:06 to 15:39, demo at 14:04
Quotes
- 10:19 "they're actually merged into uh the the base uh table and that means that a key can now span uh both base and extension fields at the same time" - A design change in table extensions that enables keys across base and extension fields.
- 11:34 "The public resources are actually consumable without a dependency." - Consumers of public resources do not need a dependency on the providing app.
- 12:55 "if you try to get a private resource by and providing the app ID, you will get an error." - A limitation: only resources in public folders can be fetched with a provider app ID.
- 13:07 "So be mindful about taking hard dependencies on specific apps on public resources because if they stop shipping it," - Warns that runtime errors occur if a provider app stops shipping a resource.
- 13:40 "that sometimes the ledger entries or some of the other the sequence entries run out of numbers." - Gives the real-world reason for the integer to big integer change.
- 13:53 "So we made it possible for you to switch to big integer by changing the type." - States the design decision to allow changing a field to big integer for large customers whose entries run out of numbers.
- 14:32 "Just changing the type itself does not change all the places where you use this value." - Warns that a big integer change needs follow-up edits in code that uses the field.
- 15:19 "but it's still allowed and it will still pass through and you can actually do this change without having to copy data" - Shows the type change passes the breaking-change check and needs no data copy or parallel implementation.
Caveats mentioned
- Changing the type does not update the places where the value is used, for example assigning it to an integer field
- Implicit conversion may overflow at runtime
- Dependent apps that have not changed to big integer can overflow at runtime
- Comparison against the previous app version reports further errors
Prerequisites mentioned
- AppSourceCop and comparison against the previous app version to see the warnings
Documented features match
- No documented item matched. No documented item
- Product documentation: Table object, checked 2026-10-02. Starting with 2026 release wave 2 (runtime 18.0), you can change existing table fields from Integer to BigInteger during upgrades. Note: Also AppSourceCop AS0146 (https://learn.microsoft.com/dynamics365/business-central/dev-itpro/developer/analyzers/appsourcecop-as0146) and compiler warning AL0662. Wave 2 content.
Docs checked on 2026-10-02: the match is against Microsoft's what's new pages for the wave as they were on that date. Microsoft keeps filling the documentation, so "no documented item" can go stale.
Tags: al, tables, upgrade, big-integer, breaking-changes, code-analysis, appsourcecop
Generated by pipeline step 06. Source: YouTube auto-captions of the launch event videos, see the deep links. Not official.