When using web services or API exposed entities you might find useful to request the application service to grab the latest version of the underlying data.
The definition at Database.SelectLatestVersion Method – Business Central | Microsoft Docs states that with using SelectLatestVersion() function you make sure that “the data displayed is the most current data in the database”.
Why would we do that? Isn’t the browser page automatically refreshed?
Not always. Not when a 3rd party up updates the records.
Let’s do some tests in a SaaS environment.
I created a custom entity (testTable), with a list page and an API page. Will start with pushing 10 records to the table via a batch using Postman:
This is the result when executing “refresh” action:
And now let’s send another batch with 4 Delete request:
Next, I’m going to send another 10 records batch to BC.
Using a new action, “refresh-SelectLatestVersion” that does not contain SelectLatestVersion() gives us the following:
It appears that SelectLatestVersion does not make any difference in SaaS and that affecting records with a BC native API does not require SelectLatestVersion().
Let’s try something similar in an On-prem installation.
When records are updated by other apps, not through Business Central means (by the way, not a great idea), the page is not notified of changes in the underlying data and therefore is in a stale state.
How can we enforce the data to update?
Using SelectLatestVersion() we’re clearing up the client cache for the underlying table, initiating a new Read transaction for the affected table, thus affecting performance.
Let’s see how much is actually taking the server to grab the latest data.
I inserted via T-SQL 1,000,000 records:
and this is what I’ve got when I refreshed the page:
The I removed all records:
As you can see above, while my CurrPage.Update is before Message, the page still shows the records. I am guessing that the Message gets displayed before the page is re-rendered.
After clicking on OK the page get rendered again and shows 0 records.
It took 69 milliseconds but the table had only 2 fields. With more fields the result might take longer.
Sometimes customers will ask for an auto-refresh page. While there are technical means to satisfy the request, we need to recognize that this comes with a price, hurting performance. And when applying an auto-refresh to multiple pages the price consequently multiplies.
Things to consider:
- avoid when possible use of Selectlatestversion on prem.
- In SaaS no need for SelectLatestVersion, refreshing the page via an action or browser F5 displays the latest data.
- avoid auto-refreshing. Rather go with a manual refresh(action on page to refresh and call SelectLatestVersion) than auto-refresh (a timer controladdin)
- To decrease the number of SelectLatestVersion() calls and CurrPage.Update, log your refresh triggers (count and refresh datetime), and compare current count against last refresh count, get the maximum System Modified At among your records and compare it against your last log datetime …
Extension code for SaaS is located here.
