Hi there, We are running Axapta 3.0 sp2, we have a batch process (part of our monthly processing) that generates a large amount of data and, among ather things, assigns tax invoice numbers. We have found from previous experiences with batch runs that performance is artificially limited on intensive processing by memory constraints per user session, as a result, we split up the process to be run per customer group with the intention of running multiple sessions to complete the batch more quickly. Unfortunately we quickly ran into a problem, these sessions end up deadlocking trying to allocate numbers from a sequence. We tracked this ton NumberSeq.release and it seems if we disable continuous numbers it should fix the problem. This seems like a bit of a hack though… is there a more appropriate way to do this? FYI we are running each of these jobs in the same company, one suggestion was that if we set up axapta to have a company representing each branch (our user groups correspond to our branches) it might fix things. Again, this seems like an inappropriate solution to me… Thanks
Hi, Try to manage with one batch-service per company*batchgroup without splitting large jobs. This is a suggestion from the documentation i got from Navision. Use a powerfull computer with a lot of memory and connect it as 3-tier FAT-client to the AOS and SQL-server via 1Gb/s NICs to use its processors instead the AOS. br,
Hi Esa, I think I may not have been clear enough on the problem. First of all, my definition of a batch process is obviously not the same as Axapata’s 
We are not scheduling these tasks as batches, but manually logging in three sessions (on the AOS server itself), and running the task for each of our three customer groups. At the moment all three groups are maintained within one company. We origonally tried running the task for all three groups (rather than splitting it up) but we had a problem halfway through and ended up having to restart, so we have rather split the process this time to avoid having the same situation. We also wanted to try and run the three groups in parallel to speed the overall process up (as I mentioned, client sessions are artificially limited as to their allowed memory usage). This resulted in a deadlock in NumberSeq.release. This does not happen if the relevant number sequences are set to be non-continuous. Thanks, Matt