To use or not to use SelectLatestVersion()

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:

  1. avoid when possible use of Selectlatestversion on prem.
  2. In SaaS no need for SelectLatestVersion, refreshing the page via an action or browser F5 displays the latest data.
  3. avoid auto-refreshing. Rather go with a manual refresh(action on page to refresh and call SelectLatestVersion) than auto-refresh (a timer controladdin)
  4. 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.

Business Central On-Premise installation: hardware and software requirements and recommendations

A list of system requirements for Business Central On-Premise is readily available from Microsoft Docs here.

The only issue is, these are bare minimum requirements.

How do we know what level of hardware requirements will be enough to not only guarantee good performance at deployment, but down the line months and years from deployment?

When the decision to go for Business Central On-Premise versus Business Central on Microsoft cloud is behind, end-users and VARs alike are facing decisions regarding the server type: should it be dedicated server in End-Users premises or virtual servers.

If going down the virtual server path, End-Users can chose between a self-managed self-hosted virtualization system (using Hyper-V or other alike solutions) or use a cloud provider(one of them being Microsoft’s Azure platform).

The minimum requirements allow for an installation of standard product. But if the company is using a different Application layer (standard + AddOns) or if the installation needs to accommodate various extensions, minimum requirements won’t be enough.

For example, in my recent experience with 2 VARs with products for Food vertical, the Microsoft Application extension has been replaced with code that includes Microsoft Application and Food application code. There are high chances that the minimum requirements won’t be satisfied by the modified base layer of the application. And with additional extensions installed on top of the base layer, our needs are getting further and further away from the bare minimum requirements.

When we need to research about Business Central requirements we need to understand the architecture of this product. Business Central functions on a three-tier architecture as seen on this Microsoft Docs page:

Each component in this model comes with their own hardware/software recommendations.

More often than not, I have seen the Web Server and the Business Central server side by side on the same server.

Quite often, especially for installations with less than 25 users, I’ve seen installations of SQL Server, NAV Server and Web Server all on 1 machine or virtual machine.

For installation of 25 users or less the topology I’ve seen working quite well is this:

  • Business Central Server + Web Server on one machine
  • SQL Server on a different machine

Business Central Server and Web Server

SpecificationMinimumRecommended
Memory16 GB>= 32 GB
Processor1 Quad Core2 x 16 CPU cores
DisksSAS or SSD Drives, configured with RAID1

For a list of Operating Systems required by Business Central Server visit Microsoft Docs recommendations for Operating System.

SQL Server

SpecificationMinimumRecommended
Memory32 GB>= 64 GB
Processor1 Quad Core 2 x 16 CPU cores
Disks SAS or SSD Drives:
– OS: RAID1
– Data drive: RAID1
– Log drive: RAID1/RAID10
– Master/TempDB: RAID1
– Backup drive: RAID1

Most SQL Server installations use SQL Server Standard.

While I’ve seen installations of Microsoft Dynamics NAV and Business Central on a SQL Server express platform, SQL Server Express should only be deployed for non-production use such as test or development environments. It is not fit as a live environment’s production server.

For a list of SQL Server OS recommendations visit Microsoft Docs page.

The three tier architecture includes:

  • Web Clients
  • Business Central mobile app
  • MS Office Applications (needed for integration of BC with Office products)
  • AL Development workstations.

Please visit Microsoft Docs for each of these additional components’ operating system and other required software recommendation.