Query READ speed performance reduced when upgrading from 2015 to 2017.

Edward_Bloomfield
Member Posts: 155
We are currently upgrading a NAV2015 customer to 2017 from 2015.
One of the features we originally added was a page that shows a consolidated view of information relating to a table like the Item table.
As we are pulling this information from four different tables (all bespoke and outside the NAV standard object range) we considered flow fields but were unable to get these to work with the complexity involved so instead we built a NAV Object to generate the data structure and then looped through this to populate a temporary table via code – you cannot build forms on Query objects unfortunately – that would be rebuilt each time someone opened the Page it was based on.
This worked OK. It would take 30 seconds or so for the page to open which wasn’t quick but the client was happy.
Whilst testing this as part of their 2017 upgrade UAT, they reported that this now took 3 minutes and 30 seconds to run, which is far too long.
We got them to bring their upgrade test server’s resources up to the level of the live one and restarted it to eliminate this as a factor but the Page/underlying query would still take 3 minutes and 30 seconds to run.
Taking the routine apart I found that:
• Running the Query directly only took a second or so.
• Remming out the code that populated the temporary table did not speed up the process.
However I found that remming out the query.READ, leaving just the query.OPEN did speed it up.
Opening the query was quick but looping through the READs has slowed right down with NAV2017:
e.g.
IF RrecObjQuery.FINDFIRST THEN
RrecObjQuery.DELETEALL(TRUE);
LqryObject.OPEN;
WHILE LqryObject.READ DO BEGIN
RrecObjQuery.INIT;
RrecObjQuery."User ID" := USERID;
RrecObjQuery."Object No." := LqryObject.No;
Is there a way to speed this up in 2017, or at least restore the performance to 2015 levels?
Many thanks in advance
One of the features we originally added was a page that shows a consolidated view of information relating to a table like the Item table.
As we are pulling this information from four different tables (all bespoke and outside the NAV standard object range) we considered flow fields but were unable to get these to work with the complexity involved so instead we built a NAV Object to generate the data structure and then looped through this to populate a temporary table via code – you cannot build forms on Query objects unfortunately – that would be rebuilt each time someone opened the Page it was based on.
This worked OK. It would take 30 seconds or so for the page to open which wasn’t quick but the client was happy.
Whilst testing this as part of their 2017 upgrade UAT, they reported that this now took 3 minutes and 30 seconds to run, which is far too long.
We got them to bring their upgrade test server’s resources up to the level of the live one and restarted it to eliminate this as a factor but the Page/underlying query would still take 3 minutes and 30 seconds to run.
Taking the routine apart I found that:
• Running the Query directly only took a second or so.
• Remming out the code that populated the temporary table did not speed up the process.
However I found that remming out the query.READ, leaving just the query.OPEN did speed it up.
Opening the query was quick but looping through the READs has slowed right down with NAV2017:
e.g.
IF RrecObjQuery.FINDFIRST THEN
RrecObjQuery.DELETEALL(TRUE);
LqryObject.OPEN;
WHILE LqryObject.READ DO BEGIN
RrecObjQuery.INIT;
RrecObjQuery."User ID" := USERID;
RrecObjQuery."Object No." := LqryObject.No;
Is there a way to speed this up in 2017, or at least restore the performance to 2015 levels?
Many thanks in advance
Edward Bloomfield
Lead Consultant
Theta
Lead Consultant
Theta
0
Comments
-
Have you checked this setting?
For a call to any of the FIND functions, 1024 rows are cached. You can set the size of the cache by using the Data Cache Size setting in the Microsoft Dynamics NAV Server configuration file. The default size is 9, which approximates a cache size of 500 MB. If you increase this number by one, then the cache size doubles.
If this is set lower than the default, you could have major speed issues. Higher than 9 will allow for large query sets.David Machanick
http://mibuso.com/blogs/davidmachanick/0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions