Most of the journal posting codeunits use the structure detailed below… OnRun(VAR Rec : Record “Gen. Journal Line”) GenJnlLine.COPY(Rec); Code; Rec.COPY(GenJnlLine); The journal line record passed to the codeunit is copied to a local version, the processing (in the Code function) is performed on the local version then copied back to the original incomming parameter version. I was told, years ago when attending a developer training course at my NTR the reason for this but I can’t remember what that reason was. Can anybody remind me?
Hi Chris, the reason is that in the function Code() the Rec is changed even if there occurs an error. if the codeunit is called from a form then the changed Rec will be saved. br Josef Metz
Josef, shouldn’t an error roll back all changes (unless, of course, there is a COMMIT somewhere in the posting routines)?
Hallo Heinz, you are right concerning database actions (INSERT,MODIFY,DELETE), but the problem here are assignments on Rec and the call from a form. You can try this in a little codeunit: OnRun(VAR Rec : Record xxx) Rec.Field1 := ‘XXXX’; Error(‘Test’); and a form based in Rec xxx br Josef Metz
Josef, From your replies… would I be correct in understanding the code construct is used to achieve a clean roll back when errors occur during posting, when the posting was called from a form? Aren’t all posting routines ultimately called from a form? Chris.
Hallo Chris, you are mostly right, but there is i.e. a report “Batch Post Sales Orders”, this report is called from Sales Orders, but you can post other Sales orders than the current Sales Order. the problem is not only the call of the posting function from the form, but also the changing the actual Rec in the posting function and returning back to the form with the changed Rec. br Josef Metz
I’d have to test this theory, but I thought that the Rec passed into OnRun is a local of OnRun, and Rec is copied into a global variable of the same record type, so it can be accessed by the whole codeunit. If that is not true, then the next theory is that putting Rec into something called ‘GenJnlLine’ makes the code a lot better to read. Remember that Navision omits the Rec part when you select a field from the object browser, and it does not do that when you access a named variable.
I’d have to agree with you Daniel (on both counts). Josef, I’ve played around a bit and I can’t provoke the behaviour you mention.