[Hardik Gupta]

Up

0

Down

::

Hi @markmckinney094gmail-com

High-volume posting with 50k+ records needs smart architecture. Here’s what works:

Performance & Batch Jobs:

– Use SetAutoCalcFields(false) at the start, call CalcFields() 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-only FindSet(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 OnAfter events 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!

[mark mckinney]

Up

0

Down

::

When extending Microsoft Dynamics 365 Business Central, it is important to maintain both system performance and data consistency. A well-designed extension ensures that users experience fast processing while business data remains accurate and reliable.

One of the best practices is to write efficient AL code. Avoid unnecessary loops, database calls, and complex calculations. Retrieve only the data you need and use filters to reduce the amount of information being processed. This helps improve system speed and reduces server load.

Another important step is to minimize database operations. Frequent reads and writes can impact performance, especially when working with large datasets. Developers should use bulk operations when possible and avoid updating records unnecessarily.

To maintain data consistency, always use Business Central’s standard validation methods and business rules. Instead of directly modifying data fields, use built-in functions and validation triggers. This ensures that all related checks and processes are executed correctly, preventing data errors.

It is also recommended to use event-driven development rather than modifying standard application code. Event subscribers allow developers to add custom functionality while keeping the core system stable and easier to update in the future.

Proper testing and monitoring are equally important. Regularly test extensions in sandbox environments to identify performance issues before deployment. Monitoring tools can help detect slow processes and optimize them when needed.

In addition, developers should limit background processes and long-running tasks. Heavy operations can be scheduled during non-business hours to reduce the impact on users and improve overall system responsiveness.

Finally, keep extensions simple, scalable, and upgrade-friendly. Avoid unnecessary customizations and follow Microsoft’s development best practices. A clean extension design makes maintenance easier and helps ensure smooth upgrades.

In summary, optimizing Business Central extensions involves writing efficient code, reducing database usage, following standard validation processes, using event-driven development, and performing regular testing. These practices help organizations achieve better system performance, reliable data, and a more stable Business Central environment.