Warehouse receipt and shipment?

Alex_Chow

Has anyone noticed that when you poste a Receipt and Shipment in warehouse management, the code does not contain any LOCKTABLE function?

We're running into problems where the Receipt and the Shipment are getting interrupted because someone else is posting a transfer order.

Anyone running into this problem? Or does the warehouse shipment and receipt calls the LOCKTABLE function, but it's just not apparent?

kriki

The codeunits call "Sales-Post", "Purch.-Post", "TransferOrder-Post*".
In these codeunits there are some locktables.

I don't have had the problem yet, so I don't know what you might do to solve it (except locking all from the warehouse posting routines).

Alex_Chow

kriki wrote:

The codeunits call "Sales-Post", "Purch.-Post", "TransferOrder-Post*".
In these codeunits there are some locktables.

I don't have had the problem yet, so I don't know what you might do to solve it (except locking all from the warehouse posting routines).

Yes, codeunits Sales-Post", "Purch.-Post", "TransferOrder-Post*" have the LOCKTABLE function. However, codeunit Whse.-Post Shipment and Whse.-Post Receipt does not use ANY LOCKTABLE.

This is creating havoc for the users when they post a large shipment or a large receipt in WHM.

kriki

To solve it, you can see here:
http://www.mibuso.com/forum/viewtopic.php?t=10025.
Problem can be that it can lock everything for quite a long time.

Alex_Chow

I believe the problem is caused by the COMMIT and LOCKTABLE function. When another function has the table locked, and you try to commit it, it'll kick out with an error.

kriki

deadlizard wrote:

I believe the problem is caused by the COMMIT and LOCKTABLE function. When another function has the table locked, and you try to commit it, it'll kick out with an error.

To avoid it you best lock all tables involved from the beginning. But you have to lock them in a certain order I don't remember. :oops: It is written in some document I don't remember. :oops: :oops: :oops:

If someone knows which is the document or the order...

And also:locking all can create performance problems. So you have to search a balance between better performance and more locking.

ara3n

Kriki The following document has this

Tuning Navision for better performance

http://www.mibuso.com/dlinfo.asp?FileID=356

kriki

Thanx ara3n
I just correct the URL: http://www.mibuso.com/dlinfo.asp?FileID=356

Alex_Chow

kriki wrote:

deadlizard wrote:

I believe the problem is caused by the COMMIT and LOCKTABLE function. When another function has the table locked, and you try to commit it, it'll kick out with an error.

To avoid it you best lock all tables involved from the beginning. But you have to lock them in a certain order I don't remember. :oops: It is written in some document I don't remember. :oops: :oops: :oops:

If someone knows which is the document or the order...

And also:locking all can create performance problems. So you have to search a balance between better performance and more locking.

Yeah, but this problem is in the standard Navision coding... :-k

kriki

deadlizard wrote:

Yeah, but this problem is in the standard Navision coding... :-k

Yes, but maybe it can be avoided by locking all tables earlier in the process (and keep them locked until the end[=not allowing the COMMIT's to run])

ara3n

Yes it's possible. I had to write a modification, where A Manifest consisted of multiple warehouse shipment documents. and I had to skip commit in order not to have an inconsistent Manifest order.

Alex_Chow

kriki wrote:

Yes, but maybe it can be avoided by locking all tables earlier in the process (and keep them locked until the end[=not allowing the COMMIT's to run])

Ok, I'm going to try calling LOCKTABLE earlier in the warehouse posting routines. I'm assuming Navision didn't use the LOCKTABLE earlier for a reason.

kriki

deadlizard wrote:

Ok, I'm going to try calling LOCKTABLE earlier in the warehouse posting routines. I'm assuming Navision didn't use the LOCKTABLE earlier for a reason.

Yes, performance. The earlier you lock tables, the earlier you block others for entering data in those tables.
PS : LOCKTABLE in itself doesn't lock the table. You have to do something like that to have a real lock:

recMyTable.LOCKTABLE;
IF recMyTable.FIND('-') THEN ;