Paul Timms
12-12-23
Operating system: Windows
We have an occasional crash bug which would be useful for a senior developer to check out. The story is this:
- A user prints an order
- Within 1 second another user creates a delivery from the same order
- System crashes with index: 1:ORVc:SHIPFLAG. D4IndexDelete found no record
- Order is not printed
After index dump and/or hard restart, record history shows:
- Delivery has been created properly
- Order has been successfully updated with Shipd1 qtys and ShipFlag = 1
- Order printed flag (Prntdf) is 0
- Printing the order sets Prntdf to 1 and the order prints
My assumption is that if the order print job is queued up, it holds the order record variable within that sequence of procedures until it can be printed. If, in the meantime, the order has been updated by another process (e.g. creating a delivery) the print job is trying to update an older version of the order and this is what's causing it to crash.