Business Central is growing in so many ways. It is growing as a platform and people’s dataset are growing in size. This brought to light a challenge, many datasets are keyed off an integer data type.
The integer in Business Central AL runs from -2,147,483,648 to 2,147,483,647. This would be a standard signed 32-bit integer system. When using as a row id we only use the positive values, which give us a hard limit of about 2.1 billion records. That sounds like a lot, but many Business Central implementation have hit that limit.
Keep in mind the the G/L Entry table uses an integer as the key, and every transaction creates one or more G/L Entries.
What are we to do about this? Well, there is the BigInteger data type. This chonkey signed 64-bit number ranges from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. That would be 9.2 quintillion values.
Okay, so just switch from Integer to BigInteger and life is good, right?
Working in Business Central AL development, changing a data type is not supported. Therefore, we can’t just go into our source code and swap it out. That is until AL Version 18 is released with Business Central 2026 wave 1.
Here is what Microsoft is saying directly from the Change Log:
Support for BigInteger field migration
The compiler now supports gradual migration between Integer and BigInteger field types:
- Field type changes (Integer → BigInteger): Changing an existing table field from Integer to BigInteger is now supported when targeting runtime version 18.0 (Fall 2026) or later. A new AppSourceCop rule (AS0141) warns about the potential consequences for dependent extensions that reference the field.
- Property context warnings: When referencing a BigInteger field in property contexts (TableRelation, CalcFormula WHERE clauses, etc.), the compiler emits warnings for narrowing conversions (BigInteger → Integer) to alert about potential overflow at runtime.
Key behaviors:
Field upgrades: Integer → BigInteger changes are allowed in upgrade scenarios
Property warnings: BigInteger → Integer,Option,Enum conversions in WHERE clauses emit warnings about potential overflow
CalcFormula support: LOOKUP, MAX, and MIN operations allow Integer ↔ BigInteger conversions with appropriate warnings for narrowing conversions
What this says is that we are going to be permitted to make the change from Integer to BigInteger. There will be lots of warning and alerts to ensure that as we change, we are checking dependencies and other data systems to ensure we don’t overflow an Integer with a BigInteger value.
This is exciting news, and it will allow for Business Central to continue to grow and meet our future needs.
Do you have any systems that have run out of Integer values? Do you plan to switch things to BigInteger in the near future? Let me know in the comments.



Leave a comment