Howdy, Stranger!
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
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 304 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Base Calendar Page very slow
Baltor1
Member Posts: 1
Hello,
In my Nav2016 the base Calendar page is very slow.
It takes minutes to open it, and when you scroll down, the page keeps hanging.
In Nav 2015 I have no problem.
Anyone an idea what's the problem?
In my Nav2016 the base Calendar page is very slow.
It takes minutes to open it, and when you scroll down, the page keeps hanging.
In Nav 2015 I have no problem.
Anyone an idea what's the problem?
0
Comments
Did this problem go away when you restarted the middle tier service by any chance?
I've had a similar issue elsewhere and strange as it may sound it was occurring because the filters being set on the virtual "Date" table were not working correctly. The debugger showed that they were active and GETFILTERS returned that they were active but a COUNT returned a large number and it took a relatively long time (a few seconds) to find the appropriate "Date" record. The problem is that this only really becomes noticeable when you are performing lots of operations on the Date record.
In fact this is not an issue specific to the "Date" table as I also encountered a similar issue on the "Field" virtual table resulting in an error occurring when opening the Purchase Order. I can't remember the exact error but it was related to the Incoming Document factbox - there was some code to find the "Posting Date" field (using the "Field" virtual table) and then some code later on that tried to get the date from the field using a RecRef. The issue here was again that although filters had been set on the "Field" virtual table, they were not all working. The code was filtering on TableNo = "38" and Fieldname = "Posting Date" (confirmed in code & debugger) but the Field record returned on a FINDFIRST was returning the Field record for TableNo 17, Field 4, FieldName "Posting Date". I.e. the "Posting Date" filter was being respected but the "TableNo" filter was being ignored. This meant that it tried to read field 4 from the Purchase Header (instead of field 20) as a Date field which resulted in the error.
I've found that these issues occur VERY infrequently and restarting the middle tier resolves the issue. The problem is that because this issue cannot be reproduced on demand I'm finding it difficult trying to get this escalated to the MS dev team.
Anyway, it would be good to know whether your issue also resolved itself by restarting the middle tier service.
P.S. If anyone else has encountered performance issues on any Date related pages (or other strange issues) which get resolved by restarting the middle tier then let me know - maybe we can find out what is triggering this strange behaviour.
Regards
Kishor