BC 29 lets a single index span base table and table extension fields

Key points

• Version 29 removes the restriction that keys must contain either all base table fields or all extension fields, but not both
• The change is enabled by storing all AL table fields in the same physical database table instead of separate companion tables
• Cross-boundary keys solve real performance problems like filtering on base table fields while sorting on extension fields
• Developers must still consider the 40-key-per-table limit and write performance costs when adding new indexes
• The capability is in public preview for online sandboxes only; on-premises guidance will follow general availability in October 2026

Quotes

• “Every index costs writes. An index that makes one list fast makes every insert and modify on that table slower.” (Critical caution for developers considering new cross-boundary indexes to avoid unforeseen performance degradation)

AL objects mentioned

As named in the post. A name that matches one object page by exact type and name links to it; the others stay as named.

• table 112 “Sales Invoice Header”
• table 32 “Item Ledger Entry”
• table 17 “G/L Entry”
• table 18 “Customer”

Context

• Features: cross-boundary keys, table extension indexing, mixed-field keys, schema storage consolidation, index optimization
• Versions: 29, 28, 23, 18

Source: Mohana’s Dynamics NAV & BC blog, community blog. Summary, key points and quotes are derived (CONTENT-NOTICE.md); read the original for the full text.