Close incom stat. bath job run more than 20 hours

Attain 3.10, DB 16 GB, use 8 dimensions. Run Close Income Statement batch job with “Close by every dimension”. Its runs more than 20 hours. I put some output information (account, dimension, line)into window. If i try to close just some accounts, everything OK. If i try to close all accounts, after some times processor show 100% and everything stopped for 10 min. After that, navision go again and i see calculation speed decreased to 1-2 entries per sec., than again pause in 5-10 min, and again some entries calculation etc. Navision can’t manage large ammount of data in 1 batch job??? Nothing helped: cache for clients until 128 MB, database free space 2 GB, commit after every account, work on local database without server… What to do??? Use faster computer and propose this “solution” for client?[:(!]

Did you notice when it’s “pausing” if in the botton part of the window it says something about “Searching…”??? If the problem is when setting some filters you can also improve the speed by setting proper keys on that process… (as example on the upgrade toolkit the first process sets wrong keys and you can speed-up that step from more than 20 hours to just one and a half…). Regards,

Not. It was may first idea about wrong keys, but keys are good. Yesterday i found these in >>>>>>>>> Response: It does not hang. It just works 100% to calculate what you asked it to (taking possibly 1 week to complete). Response: Closing an Income Statement with application of Dimensions creates General Journal lines for each possible combination of dimensions values. In your case your dimension values per dimension were: D01 – 4 D02 – 13 D03 – 190 D04 – 28 D05 – 30 S01 – 10 S02 – 7 S03 – 30 You had some 179 accounts for which you wanted these dimension values applied. This could lead to a General Journal with 3.119.669.280.000 lines (413190283010730179). Even if we assume that only 0,01% lines have actual values this wold create 311.966.928 lines in a General Journal. <<<<<<<<<<<<<<< I hope these guys from NTR are wrong, because wait for one week for close statement…[}:)]

Posting will also be fun. I first noticed this issue when posting a large(ish) customer journal. (40,000 lines). SO if you think that creating the journal is you problem, just be ready, because there is more to come. The problem in posting is that the system goes through a number of loops within loops, so for example posting 40,000 lines made 1,600,000,000 database reads during the check routine, but by breaking it down to 20,000 made only 400,000,000 reads. (Do the math!) In your case, I think the best solution, would be to forget the Close Income Statment routine, and instead, make a complete reversing line for every entry. The other way to look at it, is that you only run the routine once per year, so … maybe just live with it.

On Easter weekend we finished this function. It did 20000 entries, when in G/L is about 6 000 000 entries. So Navision did OK, but not in that way like explained in (multiply every dimension values and get more than 3 billion g/j entries). But problem still exist. Why after some time, performance decrease so dramatically (more than 10 time). I see it when look output window: at start, navision produces in g/j 10 lines per sec, after some time it not responding, and later it produces 1 line per second, and again not responding for 10 min; produces 10 lines and again… All time processor 100% busy.[?]