Overriding Table Concurrency Models in X++
Short answer
C Use the pessimisticLock keyword in the select statement to override the default optimistic concurrency model and lock the CustTable record.
Question
Two processes attempt to update the same customer record at the same time. One of the updates fails.
You need to resolve the issue by overriding the table concurrency model.
Which Select statement should you use?
Key Takeaways
This question tests the ability to override a table's default optimistic concurrency model to resolve concurrent update failures using pessimistic locking.
Resolve simultaneous update failures in Dynamics 365 Finance by overriding the default optimistic concurrency control using the pessimisticLock keyword in X++ select statements.
Common mistake: Choosing option B (forupdate) is a common mistake because while it marks a record for update, it does not override the table's default concurrency model, leaving optimistic concurrency active and prone to the same failure.
Expert Analysis
Concurrency Model Override Dynamics 365 Finance and Operations apps default to Optimistic Concurrency Control (OCC) for tables. Under OCC, if two processes select and then update the same record, the second update fails because the system detects the record version has changed since it was selected. The question explicitly requires overriding the table concurrency model to resolve this simultaneous update failure.
PessimisticLock Keyword To override the default OCC behavior and force a database-level lock at the time of selection, the pessimisticLock keyword is used in the select statement. This switches the concurrency model for that specific query to Pessimistic Concurrency Control (PCC), preventing the second process from even selecting the record for update until the first transaction completes, thus avoiding the update failure.
Evaluating the Options Option A (optimisticLock) explicitly enforces the default OCC, which causes the failure. Option B (forupdate) registers intent to update but respects the table's default OCC unless overridden. Option D (firstFast) is a performance optimization hint and does not affect locking. Option C (pessimisticLock) correctly overrides the concurrency model to apply a hard lock, matching the requirement. A community comment correctly notes that the failure indicates OCC is active, and switching to pessimistic locking resolves it.
Exam Strategy
When a question involves resolving concurrent update failures or overriding a table's concurrency model in X++, immediately look for the pessimisticLock keyword. Remember that forupdate merely signals update intent and respects the table's default OCC, whereas pessimisticLock actively overrides it to enforce a database lock.
Community Votes
79% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 1 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 1
-
cbef765 👍 1 Answered CB does not provide a concurrency method... They don't specify how you need to resolve it. If the one record failed the the optimistic method is in place (which makes sense because that is the default) If it was pessimistic then the record would have been locked. So to resolve it Id say use the pessimistic method. The optimistic catch and retry probably ran out of retries because the first user editing the record took to long.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All MB-500 Questions
Access 115 questions with complete answers and detailed explanations.
View Full MB-500 Practice Test →