in NAV version 4.00 codeunit 22, function Code, there are the followiing lines:
IF ValueEntryNo = 0 THEN BEGIN
IF GlobalValueEntry.FIND(’+’) THEN
ValueEntryNo := GlobalValueEntry.“Entry No.”;
IF ItemLedgEntryNo = 0 THEN BEGIN
IF GlobalItemLedgEntry.FIND(’+’) THEN
ItemLedgEntryNo := GlobalItemLedgEntry.“Entry No.”;
After this other functions are executed, according to the kind of posting. Fields ValueEntryNo and ItemLedgerEntryNo are both incremented by sum, but never checked again for availability.
Do you think this way of handling such sensitives keys is safe? [:(]
I have a customer who complains about occasional and totally random losses of records in table 5802 and I’m beginning to think I might have discovered why… Or am I seeing things?
BTW - I checked version 4.02: there are the same lines but the ones about ItemLedgerEntryNo come first! [8-)] Which might be the meaning of this difference?
The lock order change it’s just to prevent deadlocks. There isn’t any problem with this code because table is locked. So other users can’t read tables values and it’s safe to increment in this way.
If you check in every posting codeunit, incrementing it’s done in this way.
From codeunit 12 - Gen. Jnl.-Post Line
IF NextCheckEntryNo = 0 THEN BEGIN
IF CheckLedgEntry.FIND(’+’) THEN
NextCheckEntryNo := CheckLedgEntry.“Entry No.” + 1
NextCheckEntryNo := 1;
What I’ve been bumping my head on is actually something noboby would be able to help me with, since it is a localized and customized function. In the Italian version subcontractors are handled with purchase orders to allow to post invoices on them - I’m not sure where the localization actually begins, but I know a localization is involved from the objects numbers. The purchase orders are linked to the production orders and, when a receipt or receipt/invoice is posted against such a purchase order, instead of item ledger entries of the purchase type, capacity entries are created along with the item ledger entries of consumption and output that might be required. The posting routines doing this make a number of somersaults to achieve the expected result - sometimes they use COMMITT. [:(]
So far the standard. The receipts of subcontrcting orders, being a mess as they are, weren’t supposed to be handled in wharehouse mode, but this customer had a, now long gone, partner making a customization to allow the receipt through warehouse, adding many more somersaults. The consequences of that are now being throwed on me! [:^)]
Well, what is happening, absolutely at random, is that, now and then, the receiving process stops with an error message saying that a Dimension Ledger Entry already exists. The offending key is made of a Table ID which might be either 32 or 5802 and a entry no. which, when checked obviously comes out to be something which has nothing to do with the document being posted (usually they are sales entries, but I don’t whether this matters - don’t think so).
Thanks to the absurd number of committs the transaction doesn’t roll back entirely (but not even gets completely done, of course! [:@] ) and it is often possible to see that in the 32/5802 table, the entries preceding the one which caused the error, belong to the failed receipt as if the posting routine had taken the same number but didn’t make it to the insert because the other job got there first… or maybe it just passed the wrong number to codeunit 408, but why? …
OK. Enough ranting and whining - please, wish me good luck. I need it. [:)]
are you saying that there is code made by the Italian Localization that can cause incomplete committed transactions? If so then I would be directly contacting the Localization team and have them address it.
If its a customization, then if possible I would consider taking a look at going back to the original developer, and getting them to fix that first. I think if you keep trying to write good code on top of someone elses bad code, you will never get there.
Either way, I will wish you the good luck, you sure deserve it.
I just can’t rule out the possibility, but I have no proofs to submit to them (if I had, I would quite likely have solved the problem). Since there are customizations also involved there’s no hope they would bother to check. Actually, even if they weren’t they would ask me to reproduce the case for them, which I can’t since it happens at random and, again, if I were able to reproduce it, it would mean I know why it happens and I would be able to fix it.
I know, and I can’t even say by sure that my attempts to fix the problem didn’t add to it instead. Which would give the original developers a nice excuse to refuse to help either, even if I could reach them, which I can’t, since they were dismissed by the customer long ago.
Thank you. It was great to meet you all. The whole thing was one of the best experiences in my in life. [:)]