I find the best practice is to try and lock and read all the necessary components before the first update. That way if an item we need to update as we go along is unavailable we catch it up front and don't get "stuck". Or if you have TRANSACTION PROCESSING in place you can just to an ABORT.
I would also never just READU but do the RECORDLOCK or the READU with the LOCKED clause to be able to control program flow. You can send messages to those users that have the locked items even a text message or email. If you are in a nightly batch process then do as another suggested and keep a list of IDs and try to process them again at the end. Send an exception report via email to the ones in charge. Set inactivity timeouts on record updates that require user intervention. It would be awfully sad if Shipping can't ship because a Customer Service Rep was going to update the customers email and then got called away. Something else that helps, keep the transactional data in a separate file than the master record. For instance the Last_Shipped data shouldn't be in the same record as the Customer's Address and email. This way the customer screen can show the data in a "view only" mode with no need to lock the record that the shipping department will need to update to do its job. David A. Green (480) 813-1725 DAG Consulting _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
