NAV 2013 R2 slow performance on Config Worksheet

andrewt
andrewt Member Posts: 73
edited 2013-12-06 in NAV Three Tier
We identified a significant performance issue when using the Configuration Worksheet in NAV 2013 R2 (Table 8622, Page 8632)
Opening the page takes an unexpected long time until records are displayed, also scrolling through records and create new records is slow compared to NAV 2013 where operating this page doesn't show any performance problems.
I was able to identify some flow fields on table 8622 which reference to table 2000000028 Table Information as the source of the issue, such as field #8 "No. of Records".
Removing these fields from the config worksheet page improve performance back to a normal state.
Assuming the SumIndex calculation on the virtual table 2000000028 causing the issue, does anyone made similar experiences so far and/or has a solution for this issue ?

Thanks
Andrew T.

Answers

  • matteo_montanari
    matteo_montanari Member Posts: 189
    andrewt wrote:
    We identified a significant performance issue when using the Configuration Worksheet in NAV 2013 R2 (Table 8622, Page 8632)
    Opening the page takes an unexpected long time until records are displayed, also scrolling through records and create new records is slow compared to NAV 2013 where operating this page doesn't show any performance problems.
    I was able to identify some flow fields on table 8622 which reference to table 2000000028 Table Information as the source of the issue, such as field #8 "No. of Records".
    Removing these fields from the config worksheet page improve performance back to a normal state.
    Assuming the SumIndex calculation on the virtual table 2000000028 causing the issue, does anyone made similar experiences so far and/or has a solution for this issue ?

    Thanks
    Andrew T.

    Hi

    Same issue with NAV 2013 build 35469.

    I added this function to the page:

    GetRecordCount() Nrec : Integer
IF "Table ID" = 0 THEN
  EXIT(0);

RecRef.OPEN("Table ID", FALSE, "Company Filter");
Nrec := RecRef.COUNT;
RecRef.CLOSE;
CLEAR(RecRef);

    and changed sourceexpr of page flowfield to GetRecordCount. Now is usable.

    I think that the problem comes when NST try to meterialize every field of the virtual field "Table information".

    We need only the record count (and it's fast) but NAV try to calculate the table size even "Config. Line" "No. of Records" flowfield don't need it.

    Bye

    Matteo
    Reno Sistemi Navision Developer
  • andrewt
    andrewt Member Posts: 73
    Thank you, Matteo.
    I did apply the modifications as recommended and that worked perfectly !

    I think MS needs to fix it on standard. I did also open a support request - let's see what they come up with...

    Again, many thanks for your quick help.
    Andrew
  • mbmartinwa
    mbmartinwa Member Posts: 18
    Thanks for sharing. This is exactly what I needed too.
    Michael Martin
  • oki
    oki Member Posts: 46
    Hi,
    it seems this is not a problem of a (virtual) table Flowfield but a general issue on all Flowfields used in Pages.

    The same happens on Page 7374 Bin Contents. The Flowfield seems to be calculated every time for every single record and without recognition of any active filters. Here the field "Quantity (Base)" is slowing down the Performance massively (if there are many Warehouse Entries).
    Workaround is to delete the Flowfield from the page (Visible=FALSE,Enabled=FALSE,Editable=FALSE have no effect, it must be deleted), insert a global variable (i.e. QuantityBase) of decimal type and put following code into the triggers OnAfterGetRecord and OnAfterGetCurrRecord:
    CALCFIELD("Quantity (Base)");
    QuantityBase := "Quantity (Base)"

    and all is working without delay.

    I think the reason of the internal calculation is the new ability of filtering on flowfields. In the old forms there was a property called CalcFields where the developer could define the flowfield he wants to calculate. With 2013 there are now all flowfields in pages calculating automatically. This is propably buggy.

    Oli

Categories