how to use progress indicator in report

tneurb · 2006-01-10

Hi all Expert .Can u Tell me how to use Progress Indicator.
Where the Trigger can i put the code.

Albertvh · 2006-01-10

Hi tneurb

do the following
declare 3 variables
window of type dialog
TotalRec of type integer
CurRec of type integer

in OnPreDataItem section
window.OPEN('Processing @');
TotalRec := COUNT;
in AfterGetRecord section
CurRec := CurRec + 1;
window.Update(1,ROUND(CurRec / TotalRec * 10000,1);
in OnPostDataItem

This should do the trick

window.CLOSE;

tneurb · 2006-01-10

thank you very much

Shenpen · 2006-01-11

Note: you can use COUNTAPPROX instead of count, it is faster and was created exactly for this.

DenSter · 2006-01-11

yeah you can save a whole milisecond on that one line of code!!

Marije_Brummel · 2006-01-11

Shenpen wrote:

Note: you can use COUNTAPPROX instead of count, it is faster and was created exactly for this.

Countapprox only works differentley from COUNT if you have SQL, I think

COUNTAPPROX (Record)
Use this function to obtain an approximate count of the number of records in the table, for example, for updating progress bars or displaying informational messages.

Number := Record.COUNTAPPROX
Record

Data type: record

Refers to the table to be counted.

Number

Data type: integer

The number of records in the table.

If a filter has been set on the record, this function will behave exactly as the Record.COUNT function.

Comments
The count is approximate because it uses statistical information maintained by SQL Server, which is not kept precisely in synchronization with modifications to the table and is not under transaction control. However, it is much faster to use this information than to perform an accurate record count under transaction control, especially when there is a large number of records in the table.

Example
This example shows how to use the COUNTAPPROX function. The statement:

Number := Customer.COUNTAPPROX;

assigns the approximate number of records in the Customer table to the Number variable.

DenSter · 2006-01-11

Key quote:

If a filter has been set on the record, this function will behave exactly as the Record.COUNT function.

Modifying one line of code is usually not going to make much of a difference, it's repeated statements and inefficiencies in processing code that make a difference.

Most of the time, a progress bar slows down the process because of the constant updating. Executing one line of code takes almost nothing in terms of time, but for some reason repainting the dialog box does. If one of your reports is slow because of a progress bar, you need to limit the number of updates, say once every 100 updates, or only update every so many seconds.

Marije_Brummel · 2006-01-11

From the navision reminders:

NewTime := TIME;
  IF (NewTime - OldTime > 100) OR (NewTime < OldTime) THEN BEGIN
    NewProgress := ROUND(RecordNo / NoOfRecords * 100,1);
    IF NewProgress <> OldProgress THEN BEGIN
      Window.UPDATE(1,NewProgress * 100);
      OldProgress := NewProgress;
    END;
    OldTime := TIME;

Shenpen · 2006-01-11

Yes, it is true. I used to use Dialogs to in a MyDialog.UPDATE(1,MyItem."No.") - style for all data migration & repair programs just to avoid freezing finsql.exe and I found in awe that their performance bottleneck is not reading the database, but updating the dialog. Updating progress bars or dialogs just on every 100 records sounds like a good idea.

(Fun stuff: if you want to write a really _slow_ program, call COUNT on every record, updating the progress bar instead of storing the record count

A coworker once did it by mistake, and later on when I corrected it the client was quite surprised that a report can be made 10 times faster with only 30 seconds of hacking

)

DenSter · 2006-01-11

Hey maybe that will mke your customers happy... Make their stuff work really slow at first and then go in later and make "improvements"

ara3n · 2006-01-11

Another reason to follow your approch denster is to improve the performance gradually. As they do business, the database starts to grow and the reports run longer and longer, so if you make the report run slow at the beginning and gradually improve the performance, they won't complain 5 years down the road.

Marije_Brummel · 2006-01-11

If you design a new report, performance is part of the initial design. 8)

It is not something you do afterwards. [-X

This is why so many navision customers are dissapointed.

ara3n · 2006-01-11

I agree and the report will run at optimal, it's just you add window.update for every record, or record.count for every update, These additional functions will mimic how fast the report will run 5 or 10 years from now, and gradually you remove these functions. This whole thing was meant as joke, don't take it serously.

Savatage · 2006-01-11

Albertvh wrote:
Hi tneurb

do the following
declare 3 variables:
window of type dialog
TotalRec of type integer
CurRec of type integer

in OnPreDataItem
window.OPEN('Processing @1@@@@@@@@');
TotalRec := COUNT;
in AfterGetRecord
CurRec := CurRec + 1;
window.Update(1,ROUND(CurRec / TotalRec * 10000,1);
in OnPostDataItem
window.CLOSE;

window.Update(1,ROUND(CurRec / TotalRec * 10000,1));

1 more parentasis 8)

DenSter · 2006-01-11

Maybe we should build a dynamic performance enhancement add-on that calculates per how many records it updates the dialog depending on the number of records in the database

kine · 2006-01-12

Something like Aurora for Vista... :-)

Savatage · 2006-07-10

DenSter wrote:

yeah you can save a whole milisecond on that one line of code!!

I was just reading this post again - C'mon that's funny =D>

themave · 2006-07-10

Savatage wrote:

DenSter wrote:

yeah you can save a whole milisecond on that one line of code!!

I was just reading this post again - C'mon that's funny =D>

I tought it was pretty funny

themave · 2006-07-10

ara3n wrote:

I agree and the report will run at optimal, it's just you add window.update for every record, or record.count for every update, These additional functions will mimic how fast the report will run 5 or 10 years from now, and gradually you remove these functions. This whole thing was meant as joke, don't take it serously.

Ah, but 5 or 10 years from now they will have upgraded to a new version of Navision, and it will be much slower then the prior version, so you will need every trick you can think of to help with speed.

ara3n · 2006-07-11

themave wrote:

ara3n wrote:

I agree and the report will run at optimal, it's just you add window.update for every record, or record.count for every update, These additional functions will mimic how fast the report will run 5 or 10 years from now, and gradually you remove these functions. This whole thing was meant as joke, don't take it serously.

Ah, but 5 or 10 years from now they will have upgraded to a new version of Navision, and it will be much slower then the prior version, so you will need every trick you can think of to help with speed.

I give up. :-#

themave · 2006-07-11

ara3n wrote:

themave wrote:

ara3n wrote:

I agree and the report will run at optimal, it's just you add window.update for every record, or record.count for every update, These additional functions will mimic how fast the report will run 5 or 10 years from now, and gradually you remove these functions. This whole thing was meant as joke, don't take it serously.

Ah, but 5 or 10 years from now they will have upgraded to a new version of Navision, and it will be much slower then the prior version, so you will need every trick you can think of to help with speed.

I give up. :-#

I am only joking

ara3n · 2006-07-11

I was too :P

themave · 2006-07-11

We could start a new thread titled
"We just finished upgrading and now Dynamic Nav is so slow" [-o<

Kowa · 2006-07-11

If you add
if CurRec MOD 10 = 0 then
window.Update(1,ROUND(CurRec / TotalRec * 10000,1));

the window is updated once every 10 records. That will save more than just a millisecond on tables with many records.

fufikk · 2006-07-11

For long running reports as an "upgrade" I sometimes put info with estimated execution time. It doesn't do much but its nice to look at

dohertyk · 2007-02-07

Savatage wrote:
Albertvh wrote:
Hi tneurb

do the following
declare 3 variables:
window of type dialog
TotalRec of type integer
CurRec of type integer

in OnPreDataItem
window.OPEN('Processing @1@@@@@@@@');
TotalRec := COUNT;
in AfterGetRecord
CurRec := CurRec + 1;
window.Update(1,ROUND(CurRec / TotalRec * 10000,1);
in OnPostDataItem
window.CLOSE;
window.Update(1,ROUND(CurRec / TotalRec * 10000,1));

1 more parentasis 8)

Why is it that the "Cancel" button doesn't work?

However, pressing the escape key does?

Is there an event that I need to be testing for? Or is it supposed to be handled by the dialog itself?

Thanks in advance,

Kevin

Savatage · 2007-02-07

My Cancel button Works :-k

Mbad · 2007-02-08

Using count or countapprox sux(lol Savatage). Using the updating window when running anything sux your performance dry. If you cant avoid these do only update every 1000 or 10000 records/cycles.

Howdy, Stranger!

Quick Links

Categories

how to use progress indicator in report

Comments