You’re offline. This is a read only version of the page.
1,588
I am diagnosing an issue where one Journal Entry is imported via eConnect and it takes a long time. The transaction imported can vary from 300 to 700 lines. When at the bottom of that range, the import succeeds. At the top of that range the import times-out. Per testing by Steve Endow, a single transaction of such size should take a few seconds.
I have found the stored procedure smCleanupPostingJournalEntries is identified in a lock. As such, I am trying to understand what it is, what it has to do with importing a Journal. I don't find any other stored procedure calls this when searching the text of all the other GP procedures in the Company database.
I have read these posts and KB:
https://community.dynamics.com/gp/f/32/t/187318
https://community.dynamics.com/gp/f/32/t/142342
First, these have to do with performance during posting, not importing. The client's table contained one record when I asked last week. That record has no TRXDATE and its Journal # is 9248 - I note this because their next available number is over 66,000. So this transaction seems like it is old and/or corrupt but I cannot say why it would be problematic for this scenario.
What is the next thing I can do to investigate this lock and performance issue?
UPDATE: 2018/12/05: I realized I could identify the items in the screenshot. DBID 9 and Object 1201816485 are the target company and taGLTransactionHeaderInsert. DBID 8 and Object 518670037 are a different GP company and smCleanupPostingJournalEntries. Though I am yet failing to see why these would get into a deadlock.
*This post is locked for comments
I have the same question (0)
Share
Report
All responses (
Answers (
