>>>>I have posted something similar to this already and received one good idea but thought a different category and approach to the question would help. Sorry for the redundancy but please bear with me.
>>>>
>>>>Here is the scenario:
>>>>
>>>>You are asked to design an Invoice Form for a client/server system (generic to any back-end).
>>>>This Invoice Form will be a parent-child form using the Invoices table and the InvoiceItems table.
>>>>The main validation is that only one users changes to any part of an invoice can be saved. This means that, for example, if a user modifies an invoice by adding an invoice item line, before saving to the back end, it must be determined that no changes to this invoice have been made, either to the main Invoice table of the Invoice Items table
>>>>
>>>>i.e. consider the following:
>>>>
>>>>Both User1 and User2 are modifying Invoice 111
>>>>User1 changes the Invoice Description (parent view)
>>>>User2 changes the Quantity of a line item (child view)
>>>>User1 and User2 both issue TABLEUPDATE(0,'ParentView') and TABLEUPDATE(1,'ChildView')
>>>>
>>>>Both users changes have now been saved to the base table. This is what I'm trying to avoid. Any ideas? TIA
>>>
>>>Sounds like a good example for some type of Invoice data manager class. The class would have a property that would hold the unique key and it would have two differing update methods....one to update description, one to update line items. I'm assuming that you have some mechanism to identify what each user is allowed to update on this invoice form.
>>>
>>>IF oUser.lCandDoDescription
>>> oInvoice.UpdateDescription()
>>>ELSE
>>> oInvoice.UpdateLineItems()
>>>ENDIF
>>>
>>>Invoice.UpdateDescription would have an UPDATE SQL statement to just do the desciption. Invoice.UpdateLineItems would have an UPDATE SQL statement to update just the line items. Both would contain a WHERE clause that uses the value in the key field of this class.
>>>
>>>HTH
>>>Steve
>>
>>Hi Steve,
>>
>>The class idea sounds very interesting. However, the example you give, AFAICT, doesn't prevent the scenario from occurring. Am I missing something.
>>
>>Thanx
>
>Hi,
>
>I'm not sure it would matter. If one user can only update the header and that user saves, only the header info is going to get updated. If the other user can only update line items, only the line items would get updated. The ONLY thing both update methods contain would be the unique key identifying the invoice.
>
>You appear to have two differing views defined...one should only be the header, one should only be the line items. I'm not sure I see how one would step on the other......but I'm probably missing something here.
>
>Steve

You're correct about there being two views, one with only header info and one with only line item info. The problem is if one user updates the header info and another user updates the line item info at the same time both updates will be TABLEUPDATEd successfully. This is not the desired functionality. What is wanted is if user1 TABLEUPDATE's first then User2's will fail and vice-versa.

Bob Archer has suggested a pessimistic semaphore locking scheme which sounds promising. Any other thoughts still greatly appreciated.