Locking versus rollback

Hi, I have a question about locking of a table. What happens if a user 2 get’s a warning that a table is locked and needs to wait until user 1 is finished and then to try again. Does User 2 still sits in the piece of code where it stopped because of the table locking or has it already left all the code and is back to a screen entry for example. I’m asking because we have this issue with one of our customers. We have currently installed E-Ship from Lanham to one of our customers. That works great except sometimes we have a locking problem. There is no proper rollback when that happens. At one hand Navision is creating a Shipment and on the other hand Navision is NOT updating the Saleslines, so that the Qty to ship field is not updated. Please advise. Thanks, Roelof de Jong.

The error in rollback is most often a programming bug of the addon - new Navision versions tend to have some added COMMIT commands in new places of code what developers sometimes miss - so the commit is happening in the middle of transaction. If you have coding experience you can find the offending COMMIT yourself and restructure the code to avoid it, if not you have to ask the creator of an addon.

If it is truly a lock that needs to be released before user 2 can continue then ser 2 will sit there waiting for the table to become available before continuing with no error or rollback. If, however, it is a deadlock then an error is raised and the transaction is rolled back to the point of the last COMMIT. It sounds like this is what is happening in your case. The way to fix this is to examine the locking sequence of both processes and restructure the code to make certain that tables are always locked in the same sequence. Unfortunately it is not just a matter of looking at the two processes involved since the locking sequence for one transaction could potentially bump up against the locking sequence of any other transaction in the system. Navision has a standard locking sequence that is supposed to be used for all transactions, and to minimize problems it best to follow that sequence.

Hi Roelof, I am having th eexact same issue with e-Ship. Basically it apears that on a few rare occasions, there is an error at some point of printing the Shipping ocuments, but the document is still printed, though Navision reports the order as not shipped. Unfortuntaely the user is pushing so much data through the systme, they just havent been able to identify what causes it, and we are unable to replicate the error. Manually shipping the order seems to bring everything into sync though. We have had to add code that after printing intercepts the documents, and does a compare to see if they went trough, but myself, I don’t believe it will catch anything, since the error kills the task before it can happen. Atfirst we thought it was a locking issue, but I think that is just because eSHip does tend to be very transaction intesive, and does a lot of locking anyway, so I think the locking is not the cause or even related to this issue. I also don’t believe this to be a bug in eShip it self, but some other modification somewhere else, that is relying onthe correct use of locking sequences. Keep in mind that eShip is working at a document level, but modifying individual lines, which then link back to Document level records, so its pretty much impossible for eShip to follow the correct lockingsequences without completely rewriting the Sales Posting routines.