Issue Definition: Client has multiple service tiers. If a user on one service tier makes a change to a customer or sales order, a user on another service tier can then make a change to the original data and not receive a message that another user has changed the data.
Is there a setting change we need to make to the service tiers to prevent this from happening?
Microsoft solution
Scope Agreement: The scope of this case will be to advise on the scenario in the issue definition.
I had development review this a while back in a similar case and what you’re experiencing is expected behavior. In NAV 2016, each NAV Server has a “Listener Thread” which checks to see if there have been changes approximately every 30 secs. This check is done per table. Depending on the result of the check determines whether the cache will be flushed or not. If a record is changed on the NAV Server, then the change is placed on a “list of changes”. This list is flushed approximately every 30 secs. as well. There is one change that the previous statements don’t address which is SQL direct updates. So there is also a “Timer-Flush” that was done to ensure that cache is flushed periodically. There is a setting (DataCacheSize) in the CustomSettings.config file. Changes to this value can cause performance issues if the value is set too low which would cause data to be flushed and/or retrieved more frequently.
Example
• If a change is made on NST1 and read on NST2, it could actually take as long as a minute in the worst case. However, it is more likely to be around the 30 sec. period.
• If a change is made on NST3 and read on NST3, then the record will be available immediately.
Ways to ensure the cache is flushed in a more timely manner
• Use commits to force the cache to be flushed
• Use a LOCKTABLE followed by a FIND will flush the cache for that particular table.
Problem: using the solution supplied will require changing massive amounts of standard code.
This seems like a major design flaw.
I am hoping the SQL Server experts in the Dynamics NAV group could come up with a much better solution.
Is there a setting change we need to make to the service tiers to prevent this from happening?
Microsoft solution
Scope Agreement: The scope of this case will be to advise on the scenario in the issue definition.
I had development review this a while back in a similar case and what you’re experiencing is expected behavior. In NAV 2016, each NAV Server has a “Listener Thread” which checks to see if there have been changes approximately every 30 secs. This check is done per table. Depending on the result of the check determines whether the cache will be flushed or not. If a record is changed on the NAV Server, then the change is placed on a “list of changes”. This list is flushed approximately every 30 secs. as well. There is one change that the previous statements don’t address which is SQL direct updates. So there is also a “Timer-Flush” that was done to ensure that cache is flushed periodically. There is a setting (DataCacheSize) in the CustomSettings.config file. Changes to this value can cause performance issues if the value is set too low which would cause data to be flushed and/or retrieved more frequently.
Example
• If a change is made on NST1 and read on NST2, it could actually take as long as a minute in the worst case. However, it is more likely to be around the 30 sec. period.
• If a change is made on NST3 and read on NST3, then the record will be available immediately.
Ways to ensure the cache is flushed in a more timely manner
• Use commits to force the cache to be flushed
• Use a LOCKTABLE followed by a FIND will flush the cache for that particular table.
Problem: using the solution supplied will require changing massive amounts of standard code.
This seems like a major design flaw.
I am hoping the SQL Server experts in the Dynamics NAV group could come up with a much better solution.