I am trying to understand why Nav does not have a batch recovery system (like GP). I know when you ie. create an invoice in Nav nothing is committed until you hit post and sql posts all the transactions relating to that invoice at once. I assume the odds of having a computer crash during that nano second when everything is posting is slim but possible?? I assume if it does happen nothing will committ to posting and you will have to only re-post (or redo everything from scratch like the invoice?). I’ve heard that GP has a batch recovery for such cases (though as I’ve been informed with GP is that it makes a record as data is entered) but posts all transaction at once as well. If someone has there head around this I’m curious to find out why. We’ve been having this convo in the office and I would like to shed some light on it.
If your computer crashes during posting of an invoice, the entire transaction will be rolled back. When you get your system back up, the invoice will still be there in an unposted state, and you can attempt to post it again.
Your assertion that NAV ‘doesn’t have a batch recovery system’ is unclear to me though, it’s not quite clear to me what you are asking. First of all, it is not SQL that posts anything, it is all logic that runs inside the NAV client session (or in an automated version of the NAV client session called NAV Application Server, which is essentially a regular NAV client session that runs as a Windows service). Then I guess I am having a hard time understanding what it is exactly what you are asking about when data is entered as opposed to when invoices are posted. When you create an invoice, you enter data, at this point it’s nothing more than an intention to process a transaction. The invoice itself though is definately committed to the database as an open document, it is just in an unposted state, and as long as you don’t post it it will remain an open document. When you run the posting process, it ‘translates’ the invoice into financial transactions, and writes ledger entries into the financial history. Usually you post invoices one by one, although there is a batch program available that posts multiple invoices in one batch. I don’t have any experience with GP, but I am guessing that this is essentially the exact same process, and there are similar processes at work.
Are you asking about how partially posted batches are handled in case of failure? This depends on how the batch is implemented. I believe that in NAV’s case, the entire batch is considered to be one giant transaction. If it fails at any one point, the entire transaction would be rolled back as if it never started. It might be though that there are intermediate points where individual invoice postings are committed as they finish, and this could be modified for individual implementations.
The point is, NAV should not need any ‘batch recovery system’, because it should not have any incomplete transactions. Either they post completely, or they roll back as if nothing ever happened.
After each invoice a COMMIT is lauched. (and there are also some extra COMMIT’s in the posting of a document. Like after calculating the invoice discount (if used) or releasing the invoice [if not done yet]).
So if an invoice has an error, it is is skipped and the next invoice is posted. Also when the client that is posting crashes, you can restart the batch and it will post the invoices that aren’t posted yet.
Thanks Alain I wasn’t completely sure[:)]