ArcherPoint Dynamics NAV Developer Digest - vol 262
The NAV community, including the ArcherPoint technical staff, is made up of developers, project managers, and consultants who are constantly communicating, with the common goal of sharing helpful information with one another to help customers be more successful.
As they run into issues and questions, find the answers, and make new discoveries, they post them on blogs, forums, social media…so everyone can benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this community—so we thought, wouldn’t it be great to share this great information with everyone who might not have the time to check out the multitude of resources out there? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from NAV experts and devotees around the world. We hope these insights will benefit you, too.
Dynamics NAV Filter Group Number Warning
Kyle shares his Developer Tip of the Day: Be careful which filter group numbers you use. The article I posted a couple of days ago leaves out the description of the system-used group numbers. This is from the 2015 developer help:
A filter group can contain a filter for a Record that has been set earlier with the SETFILTER Function (Record) or the SETRANGE Function (Record). The total filter applied is the combination of all the filters set in all the filter groups.
When you select a filter group, subsequent filter settings by the SETFILTER Function (Record) or the SETRANGE Function (Record) apply to that group.
All groups are active at all times. The only way to disable a group is to remove the filters set in that group.
Filters in different groups are all effective simultaneously. For example, if in one group, a filter is set on customer numbers 1000 to 2000, while in another group, a filter is set on customer numbers 1800 to 3000, then only numbers in the range 1800 to 2000 are visible.
Microsoft Dynamics NAV uses the following filter groups internally.
Number Name Description
-1 Cross-column Used to support the cross-column search.
0 Std The default group where filters are placed when no other group has been selected explicitly. This group is used for filters that can be set from the filter dialogs by the end user.
1 Global Used for filters that apply globally to the entire application.
2 Form Used for the filtering actions that result from the following:
- SETTABLEVIEW Function (Page, Report, XMLport)
- SourceTableView Property
- DataItemTableView Property
3 Exec Used for the filtering actions that result from the following:
- SubPageView Property
- RunPageView Property
4 Link Used for the filtering actions that result from the following:
- DataItemLink Property (Reports)
- SubPageLink Property
5 Temp Not currently used.
6 Security Used for applying security filters for user permissions.
7 Factboxes Used for clearing the state of factboxes.
A filter set in a group different from filter group 0 cannot be changed by a user who uses a filter dialog to set a filter. If, for example, a filter has been set on customer numbers 1000 to 2000 in group 4, the user can set a filter that delimits this selection further but cannot widen it to include customer numbers outside the range 1000 to 2000.
It is possible to use one of the internally used groups from C/AL. If you do this, you replace the filter that Microsoft Dynamics NAV assumes is in this group. If, for example, you use filter group 4 in a page, you will replace the filtering that is actually the result of applying the SubPageLink Property. This could seriously alter the way pages and subpages interact.
Using filter group 7 may cause factboxes to not work as intended.
To reset the filters in filter group 1, you add an empty filter to the group. To add an empty filter to filter group 1, you must first set the filter group.
Then, for each field in the table that to which the Rec variable refers, set an empty filter.
NAV 2017 Job Queue Entry Issue
Ed is looking for help: “Has anyone seen where the JOBQ skips the exact interval that the job is set to run? The customer is on NAV 2017, and a job that is scheduled to run every day at 4:20 runs every other day. A job scheduled to run every Wednesday night runs every other Wednesday and so forth. I compared the Codeunit 448 Job Queue dispatcher to other versions, and the code to calc next start time is the same.”
Kyle notes: “That either sounds like a strange setup on each job queue entry or some sort of bug that might be addressed in a cumulative update. If you have the JQE set to run every 24 hours and also have it set to run at 7:00 AM every day, that might result in every 48 hours.”
Ed notes: “It is ALL entries they have set up, not just the dailies. If something is set to run every Friday night, it will run tonight and then run again in 2 weeks instead of next Friday. They just told me about it. The code that set the NEXT scheduled start date is simple.”
Matt T adds: “It does set the next scheduled run time based on when the job ENDs. Don’t forget that.”
Ed replies: “The job runs in 1 second because there just so happened there was nothing to do today. I just set the job to run at 11:20. I watched as it DELETED the jobq entry and recreated it with next start date time of 09/29/19 11:20?”
Faithie chimes in: “It might be worth it to check the time zone the server is on as well, Ed. I’ve seen some crazy things happen when this was incorrectly set.”
Ed concludes: “I found where in our version of 2017 the CalcNextRunTimeForRecurringJob is being called twice, once before the job runs and once after, which explains why it jumps ahead one occurrence. I did a closer compare to 2016 and 2018, and the extra line is in table 472.”
If you are interested in Dynamics NAV and Business Central development, be sure to see our collection of NAV/BC Development Blogs.
Read the “How To” blogs from ArcherPoint for practical advice on using Microsoft Dynamics NAV and Dynamics 365 Business Central.