Business Central 29.0: Major Change to Table Extensions and SQL Storage.
Business Central 29.0 changes how table extension fields are stored in the database, moving from a companion-table model to storing extension fields directly in the same SQL table as the base table. This enables cross-table indexes, can improve query performance, and requires developers to avoid direct SQL dependencies.
Read it hereOpen in Claudetag-blogger-com-1999-blog-3122193036149030463-post-5876765753602227342--dc85fd75c1.md
post Saurav Dhyani
"Developers can define indexes that span fields from a base table and its table extensions."
Key points
- Extension fields now physically reside in the same SQL table as base table fields instead of separate companion tables
- Developers can create indexes spanning both base table and extension fields for more flexible data access patterns
- Database operations involving extensions may perform faster due to co-located storage of all fields
- Partial record loading remains important despite the new storage model; developers should continue using SetLoadFields appropriately
- Solutions should depend on AL and Business Central APIs rather than direct SQL, as physical schema is an implementation detail that can change
Quotes
- “Developers can define indexes that span fields from a base table and its table extensions.” (This new capability enables more flexible data access optimization that was impossible with the previous companion-table approach)
Context
- Features: Table extension data storage, Cross-table-extension indexing, Partial record loading, SQL column-limit compiler warnings, Data model evolution, Performance optimization for extensions
- Versions: 29.0
Source: Saurav Dhyani, community blog. Summary, key points and quotes are derived (CONTENT-NOTICE.md); read the original for the full text.