In earlier versions of Dynamics NAV, specifically up to NAV 4.0, certain functions were written in order to speed up processing in the Native client. However, when moving to SQL platform, these functions can cause performance issues in large databases. For the purpose of performance optimization, there is a special service many NAV solution centers offer to their clients – code optimization.
This procedure is highly recommended, especially in the following cases:
- When doing a NAV upgrade from Native to SQL client
- When there is a big gap between the upgrade versions
- If the customer’s database is really large in size
The following new functions are usually introduced in the upgraded code:
The following functions are considered as causing performance issues:
- FIND (‘-‘)
- FIND (‘+’)
Let’s look at the FIND functions specifically in order to understand the difference in their way of processing data on Native and SQL server.
Before the new functions were introduced, when the NAV system was told to FIND(‘-‘) – what it did is select all records from the table (according to the applied filters, if any).
In the SQL query, it would show a SELECT * FROM… statement.
If our FIND function did not contain a condition check and was looping through three times, like:
IF FIND(‘-‘) THEN MESSAGE…
Then in the fourth attempt NAV will select only one record in order to optimize the process. In other words, on the fourth time, NAV will transmit FIND(‘-‘) to SQL as
SELECT * TOP FROM…
If there are thousands of records, in the first case, the system might not be responsive or will perform the request slowly, which causes complaints from the users.
Starting from Navision 4.0, we have the opportunity to choose whether we want to select one record (FINDFIRST/FINDLAST) or all records (FIND(‘-‘)/FIND(‘+’)).
Another powerful function is FINDSET. It is used when you want to look through a record set, and should be utilized in combination with the REPEAT..UNTIL clause. This function is optimized for finding and modifying sets of data, without creating cursors (and without using FETCH commands called on SQL server). However, this is only valid for the first 500 records (this number can be changed in the NAV Database properties and can be increased if needed). After these default 500 records, the loop will still create a cursor, like in the old NAV versions.
Another useful function is called ISEMPTY. The following code is usually replaced by it. So, for example:
IF NOT Customer.FIND (‘-‘) THEN…
IF Customer.ISEMPTY THEN…
This tells the system to check if the record exists in a filtered range of data, but we do not need to get a value itself from the record.
COUNTAPPROX is another function which optimizes the performance of the NAV system. It is used in order to update the progress bars and display informational messages. The COUNT function asks the server to count the number of records in a table, thus sending a query:
SELECT COUNT (*) FROM
However, if we utilize the COUNTAPPROX function, SQL server does not create a query, but instead creates a QEP (query execution plan) so the server does not actually do a record count, but instead prepares an estimated number of rows within the filtered range of data. Since it’s used in updating the progress bar, we do not need the actual record count.
Apart from optimizing code within the NAV system, the following procedures can help troubleshoot the performance issues of the system:
- Low performance objects (e.g. financial reports which process huge amounts of ledger data) should be analyzed with the SQL Server Profiler and Tuning Advisor
- Indexes of the master tables should be optimized
- Statistics should be updated
- Special NAV benchmark toolkits can be used to debug slow performance
This activity is time-consuming and it is necessary to have specifications on the customized functionality and the server parameters from the customer side. In addition, a list of the most crucial low-performance issues must be provided.
Performance issues are often a complaint from users after the upgrade, which means that their database needs optimization. As described above, this process includes the work with the NAV code itself, the SQL Server tasks, as well as the optimization at the data level (compressing ledgers, removing log entries, etc.)
To ensure a smooth procedure, the system health check and performance diagnostics should be performed and a list of recommendations should be presented and discussed with the customer.