NAV2016 - Long wait after having reached 100% when posting G/L Journal

pdj
pdj Member Posts: 643
in NAV Three Tier
When I'm posting a G/L Journal with 8000 lines, then NAV nicely updates the progress bar the first 50 seconds and reaches 100%.
Then NAV freezes for about 8-9 minutes without any sign of life, before it tells me it is done.
I have tried to troubleshoot with the Application Profiler, but it has a top-level dummy SQL statement which it claims is accountable for 7-8 minutes. The rest is the basic posting, which seems ok. I then guessed it would be the buffered insert, but disabling that for the NAV Service Tier doesn't change anything.

Any good ideas before I try troubleshooting using the SQL-Profiler?

(At the customer test site it is even worse. The exact same journal takes appr. 5 minutes to reach 100% and then freezes for appr. 45 minutes.)
Regards
Peter

Best Answer

Answers

  • jglathe
    jglathe Member Posts: 639
    There is a performance fix for this now:

    https://markbrummel.wordpress.com/2016/10/03/performance-issue-with-workflow-solution/

    with best regards

    Jens
  • mdPartnerNL
    mdPartnerNL Member Posts: 802
    Good work.
  • Andwian
    Andwian Member Posts: 627
    jglathe wrote: »
    There is a performance fix for this now:

    https://markbrummel.wordpress.com/2016/10/03/performance-issue-with-workflow-solution/

    with best regards

    Jens

    I do not know why what's wrong with my code, but the issue is still persist.
    pdj wrote: »
    A friend found this link for me: https://community.dynamics.com/nav/f/34/t/186493

    It turns out the event subscribers are causing the problems. I ended up deleting the following subscriber functions and got a proper performance again:

    Codeunit 1535: DeleteApprovalCommentsAfterDeleteGenJournalLine()
    Codeunit 1535: DeleteApprovalEntriesAfterDeleteGenJournalLine()
    Codeunit 1550: PostApprovalEntriesMoveGenJournalLine()
    Codeunit 1550: CustomerCheckGenJournalLinePostRestrictions()
    Codeunit 1550: GenJournalBatchCheckGenJournalLinePostRestrictions()
    Codeunit 1550: GenJournalLineCheckGenJournalLinePostRestrictions()
    Codeunit 1550: RemoveGenJournalLineRestrictionsBeforeDelete()
    Codeunit 1550: RestrictGenJournalLineAfterInsert()
    Codeunit 1550: RestrictGenJournalLineAfterModify()
    (I simply used the List of Event Subscriptions to find those called many times)

    Pretty sad :-( I was just getting fond of the Workflow feature, but it is almost useless when it affects the performance like this.

    I just delete 3 subscriber, then it works. Must delete the subscriber, not just remark the code:

    COD 1550
    RemoveGenJournalLineRestrictionsBeforeDelete
    COD 1535
    DeleteApprovalEntriesAfterDeleteGenJournalLine
    DeleteApprovalCommentsAfterDeleteGenJournalLine
    Regards,
    Andwian

Categories