Last week, I wrote about the table extension storage change in v29 base table fields and extension fields now living in one physical SQL table instead of two. I framed it as a change that made extension architecture simpler and faster. It is. But every unification creates a shared resource where there used to be separate ones, and a shared resource needs a way to tell you when it’s running out.
Version 29 just shipped that warning, and I think it’s worth treating as the second half of the same story rather than an unrelated feature.
The Column Budget Just Became Everyone’s Problem
SQL Server enforces a hard limit on the number of columns a table can have. Before v29, that limit applied per physical table the base table had its own budget, and the shared companion table holding every installed extension’s field had its own separate budget. A table with a lot of extensions installed could still run into trouble, but the two pools were at least distinct.
Once base table fields and extension fields share one physical table, they share one column budget too. A base table that’s accumulated years of fields, combined with every extension that’s added its own fields on top of it, now draws from the same finite pool. Nobody planned for that pool to be shared, because for most of Business Central’s history, it wasn’t.
What the New Warning Actually Catches
Microsoft has added two compiler warnings addressing this directly. AL0914 fires when a table itself has accumulated a large number of fields independent testing confirms this triggers with a message stating plainly how many fields a table has once it crosses the threshold, flagging that a table with many fields limits how much room remains for any extension trying to add fields to it. AL0915 fires from the other direction — when a single table extension adds a large number of fields to a table, warning that doing so may limit the ability of other extensions to add fields of their own to that same target table.
Together, these catch the same underlying risk from both sides: a base table that’s grown too large on its own, and an extension that’s claimed too much of the shared budget for itself. The deployment failure message that appears when an app actually hits the hard limit during installation has also been updated to reflect the new shared-table reality, rather than describing the old two-table model.
Why This Is a Governance Feature Disguised as a Compiler Warning
A compiler warning is easy to file under “developer tooling” and move on. I think that undersells what’s actually happening here. This warning exists because a single extension can now, structurally, limit what every other extension on that table is able to do — and on a widely extended table like Customer or Sales Header, “every other extension” can mean dozens of unrelated apps built by different ISVs who have never coordinated with each other.
Before v29, an extension adding fifty fields to its own companion table space was mostly its own business. After v29, an extension adding fifty fields draws directly against a pool every other extension on that table also depends on. The warning is Microsoft’s way of surfacing a cost that used to be invisible: your field count now has consequences for other people’s extensibility, not just your own table’s performance.
What This Means in Practice
For anyone maintaining an extension with a large number of fields on a heavily shared base table, this is worth testing directly against the v29 preview rather than assuming the warning won’t apply. Run a compile against a table you know carries a lot of fields already, and see where AL0914 and AL0915 actually trigger relative to the real SQL column limit — the threshold that matters in practice, not just the theoretical one.
For anyone building on tables like Customer, Item, or Sales Header specifically, it’s worth treating this as a reason to reconsider whether every field a new extension adds genuinely needs to exist on the base table, versus being modeled in a separate table with a relation back to it. That tradeoff existed before v29 too, but it had lower stakes when your extension’s field budget wasn’t shared with every other app touching the same table.
Finally
The table extension redesign gave developers real capability — faster performance, unified storage, indexes spanning base and extension fields for the first time. This warning is the part of that story that doesn’t get a keynote slide: shared resources need shared accounting, and a platform mature enough to unify storage across extensions is also mature enough to warn you before that shared space runs out.
Treating AL0914 and AL0915 as routine compiler noise misses the point. They’re the mechanism that makes the storage unification sustainable at scale, on tables where dozens of independent extensions have to coexist without any of them being able to see what the others are doing to the same shared budget.
Leave a Reply