I promised to myself not to post technical stuff on this blog. But as Seth Godin said not that long ago, never’s not such a long time. And also, why shouldn’t I share a piece of useful advice if I have it. So here it goes.
Have you ever started a lengthy NAV batch job, and then wondered how much longer it is really going to take? Me too.
NAV forms usually have progress bars. Good. But how about something like this:
Instead of just sporting a progress bar, it gives you estimated time left. Now you really know if you can go grab that sandwich while NAV munches on its bytes.
Here’s how I did it:
- At every row, calculate the difference between current time and batch job starting time
- Based on this, the number of records completed and total number of records, you calculate the total estimated operation time length
- Add the total estimated length time to starting time
- Calculate the difference between estimated ending time, and current time
- Display the number
In C/AL, it looks like this:
iTotal := lrSomeTable.COUNT;
i := 0;
iPctg := 0;
dtStart := CURRENTDATETIME;
dtDiff := 0;
dWindow.OPEN(Text001,i,iTotal,iPctg,dtDiff);
// Text001 =
// Copying parameters: #1####### of #2#######
// @3@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\
// Estimated time left: #4###################
IF lrSomeTable.FIND(‘-‘) THEN
REPEAT
// do something
i := i + 1;
iPctg := ROUND((i / iTotal) * 10000,1,'<‘);
dtDiff := ROUND((CURRENTDATETIME – dtStart) * (iTotal / i),1,'<‘);
dtEnd := dtStart + dtDiff;
// We don’t care about milliseconds
dtDiff := ROUND((dtEnd – CURRENTDATETIME) / 1000,1,'<‘) * 1000;
dWindow.UPDATE();
UNTIL lrSomeTable.NEXT = 0;
Of course, this is just a rough estimation, it totally depends on statistics, and that each operation of whatever you do with your records will take roughly equal amount of time.
How about including this in status forms of your next NAV 4.0 to 5.0 upgrade project?
Vjeko,
yesterday after several hours of “#$%&%&%$#$#$%” I made upgrade NAV 4 SP3 HR to NAV 5 SP1 HR of one not so complicated database.
Can you help me to understand where are dissapeared Field 5802 “Value Entry No.” in Table 17, and several fields in Table 5802 related to Table 17 !??
I remember several custom made reports in older versions (<= 4) laying on those relations between two Tables.
P.S.
I hope so this is not only technical question ?
Best regards to You !
Dalibor Matkovic
Hi Dalibor,
Sorry for not replying earlier – I was busy, and didn’t check my blog for comments. I don’t know the answer to your question, but I believe you can check the 4.0->5.0 and 5.0 SP1 upgrade toolkit. There have been many changes in costing between 4.0 and 5.0, and I believe that the changes you are talking about are related to these.
Best regards,
Vjeko
Here is an improvement of this down-counter. As you know any updating of the screen (dWindow.UPDATE();) takes quite a lot of computer time – sometimes much more than the primary task system needs to do. So updating screen in every pass can increase your weight due to too many sandwiches 🙂
So why not calculating first if specific time has passed since last update (1 sec, 5 sec). This will run much faster at an insignificant cost of storing time of last update, because you skip many screen updates, which you never notice because of rounding milliseconds.
BTW, by implementing this I often noticed that suddenly I don’t need to show remaining time anymore. 🙂
Robert: Yes, you are right. In the end, I decided to call UPDATE only once per second. I didn’t however do the other trick you mention: wait for 5 seconds before displaying it for the first time. As always: there is a lot I learn from you! 😉 And you are almost right when you say that you don’t need to show remaining time anymore – the problem is, for the operation I needed to track, it sometimes took 15 minutes, sometimes 30 minutes, once it even took 50 minutes – something I definitely want to track every time.