>Greetings all,
>
>I'm currently having data update problems in a multiuser environment. I'm guessing that this problem existed in earlier versions of our application but is quite apparent right now.
>
>When a single user creates or edits an invoice ( or order draft, etc..) everything is okay ( all the proper tables are being updated ) but as soon as we have multiple users editing and creating, sometimes a few of the tables won't be properly updated, for example, the numbers in the inventory will be wrong.
>
>I'm sure there is no "quick-fix" to this problem (but still hoping there is) but i'm looking for any ideas or things to watch for.
>Transactions are in use as follows when the user clicks the "Finish" button:
>Begin trans
>mess with data (replace, etc..)
>tableupdate(1, .f., 'sometable') (as many as needed.. also the error handler will alert me if update conflict occurs, which it hasn't, so I assume no update conflicts)
>end transaction
>
>sometimes many transactions will take place, with no messing with data between transactions.
>
>---
>Praying for a miracle, ;-D
>Jonathan Chan
>
>---
>Thanks all, UT has helped a great deal in the past and now I'm back for more ;-)
>One day, I hope to be able to help out as much as others have helped me.

Jonathan;



I have created a number of inventory applications alone and with teams of developers. One of the problems is correct inventory count. User A requires 10 items of type 1 and user B requires 20 of the same item. There are 20 in stock and user B completes his/her transaction first. User A completes his/her transaction and you have –10 items. Add to this committed and backlog stock.

The problem in this case is due to the type of locking selected. If you choose optimistic locking you are going to have a problem. So we used pessimistic locking for anything to do with quantities and currency.

So I would ask you to check what is failing. Make a detailed list and begin to examine it closely. Check the type of locking you are using in the places that fail. To best understand this type of problem create a form with the basic required functionality. Instantiate this form twice on your computer and begin adding and subtracting inventory. Keep a table of what you should have before you begin. In other words write a script with the expected results. You reset your quantities to insure your starting point after each attempt. Experiment with SET Reprocess and trapping for any errors that may be generated. Once you have the concepts down I think you can move over to your live application.

I hope what I have said makes some sense and will be of assistance.

Tom