Dynamics Business Central (NAV)
Experts:
How to Optimize Performance and Data Consistency When Extending Business Central
-
How to Optimize Performance and Data Consistency When Extending Business Central
Hi Community,
Iām currently working on extending Microsoft Dynamics 365 Business Central (cloud, latest version) using AL, where we handle high-volume transactional data (50k+ records/day). Iām facing challenges related to performance degradation and data consistency, especially when implementing custom logic in posting routines and integrating with external APIs.
Here are the specific concerns:
Long execution times when processing batch jobs (e.g., posting sales invoices with custom validations).
Database locking issues, leading to occasional deadlocks when multiple users/processes run simultaneously.
Maintaining data integrity while using temporary tables and background sessions.
Best practices around event subscribers vs direct code modifications for scalability.
Efficient use of SetAutoCalcFields vs CalcFields in large record loops.
-
1 Reply
-
High-volume posting with 50k+ records needs smart architecture. Here’s what works:
Performance & Batch Jobs:
– Use
SetAutoCalcFields(false)at the start, callCalcFields()only when needed– Use QUERY objects instead of looping, optimized at DB layer
– Break batches into chunks via Job Queue (1000 records/job) instead of one massive batch
– Separate custom logic from posting using Codeunit.Run(), keeps transactions clean
Locking & Deadlocks:
– Only use
FindSet(UpdateLock)when modifying. Use read-onlyFindSet(false, false)otherwise– Keep transactions SHORT. Commit frequently, don’t wrap entire batch in one transaction
– Avoid nested events, use a “processing flag” to prevent chain reactions
Data Integrity with Temp Tables:
– Use temp tables for staging/validation (isolated, no locking)
– Validate first in temp table, commit only if all checks pass
– Use StartSession() for background work with explicit error handling
Events vs Code Mods:
– Keep event subscribers lightweight, heavy logic = slow posting
– Put business logic in separate Codeunits, call from events
– Use
OnAfterevents for critical logic (order is predictable)CalcFields Optimization:
– Don’t call inside loops, calculate once, store in variable
– FlowFields are expensive at scale; consider denormalizing with a cache table if needed
For 50k+ records, architecture looks like:
Batch Job ā Temp Table Validation ā Background Sessions (chunked) ā Event Subscribers ā External API (async)
Happy to review your posting routine specifics if you want to dig deeper!
Log in to reply.
