I know that version 3.7 is no longer being supported but I have a HUGE problem.
When posting general Journal lines it takes ages to do the posting. Every month we have a journal with approx 60.000 lines. When trying to post it the calculated time to do the posting is more than 100 hours.
In the very same journal we have tried to set filters for eg 500 lines but the posting time is still the same.
If we instead generates 60 journal templates with 1000 lines each, the posting can be done in less than two hours.
As far as I remember this have been reported by others a long time ago either here or at partnersource - but I can not find solution anywhere on the website.
Any good suggestions would be highly appreciated.
I have not given any information about HW, SW, DB as this is of no importance - I think its a code issue.
Hi the free space is more than 20% … i think at least you should have 50% free …that 's what i know , may be any of experts will advice us about this point …
if your runnthe posting on the server directly , do you need the same hours ?
Sometimes yes hardware or networkconnection will affect … make sure of all those things before determining the problem of codeunit 12 .
I am having the same problem in Batch Report 795 adijust cost entries and i am still tracing to check the error . …
3.7 + SQL2005 is rather uncommon, not to say, unsupported, but that shouldn’t be the reason.
With 3.7 there where still problems with:
How many Dimensions are involved?
How many “update on posting” Analysis Views + how many Dimensions each AV maintain?
I’ve seen a situations, when sync update of both while posting numerous Journal entries could cause even deadlocks in 3.7 - first aid was disabling “update on posting” for AV (MS reccomendation).
and even it was in 3.7 - THIS can’t be optimized, an upgrade (might) help…
Yes I am back… No need to merge the accounts just delete one of them. My problem was that I could not login (memory fault of password) and the recovery function was to slow at the moment.
Most likely this is a memory issue, it will at least play a big role. The memory fills up and the server starts paging the information. I think the best answer is something you’ve already figured out, and that is to split the journal up into multiple batches. Another issue might be network load, with a batch that big there’s an awful lot of information going back and forth between the client session and the server. Have you tried running this during off hours, directly on the server?
3.7 is not supported on SQL Server 2005 by the way, never has been, those versions are officially not compatible.
On SQL Server you don’t have to have a certain percentage of free space, not for performance purposes anyway. SQL Server does not use the actual data file for temporary storage like the NAV database server does. You can have a data file that is 99% full and still have good performance on SQL Server. Having some free space is recommended of course, but for different reasons.
