Somehow I have created a situation that locks a form when in the UPDATE mode. 

The main Orders form has two Line Item subforms, both are Table View.
In @ADD mode, Subform A is visible, Subform B is invisible.
In @UPDATE mode, Subform A is invisible, Subform B is visible.

In @ADD mode, all is well, Can create new record with multiple line items in subform

In @UPDATE mode, main form is locked. Yellow Mode indicator shows LOCKED status. 

Can make changes to fields in subform, but values in the first record only are not saved.  Records 2 and subsequent accept the changes, and are saved.  Making these changes undoes the Locked status and all lines after the first are saved.

I suspect that this is related to focus changing from main form to sub form and triggering of events on both forms on Entry/Exit. 

Thoughts, suggestions, answers?

Good news is that you have identified the cause of the "common problem". 

And what is the "common solution"? 
Cannot have multilple subforms to the same database?
Cannot have common fields on the multiple subforms?
Is there a method to SetFocus, or unload FormA so FormB does not have a conflict?

Quote:


I believe that Ray meant "common" in the sense of shared - not in the sense of frequent.

Quote:

If you have two forms both sharing the same data source record, one of them must be locked, just as if you had them open on different clients. The locking in Sesame is first come first serve.

Quote:

Same database is fine - but two forms trying to access the same record simultaneously is a problem. One or the other has to "own" that record. Without locking you could easily have data overwrite, especially if this is a programmed database.

Quote:

See above.

Quote:

Yes, in programming there are a number of commands that set focus, move focus, and much more to the point - advance records.

Record locking is a necessary and important part of data integrity. Anything that bypasses it or "works-around" it, should be done with the utmost care.

What is the end-user requirement you are trying to fulfill? It may well be that the best solution is to use programming to the transfer the record data to a separate set of LEs that are not themselves "sourced" to the same record or database as the original form's LEs. That way, the original form acts a secondary "source" of the data, and programming can be used to decide, on a case by case basis, what data is shown (and how) and commited.

This can be accomplished by using either the string array commands along with the generic LE access functions to glean the form data from the invisible form and cycle its records and storing the data in the Global Code area, or by deriving the data directly from the invisible form at each advance, writing the resulting user input back to the form before advancing. If the data, in either case, can be displayed "read only", I would recommend that you use static LEs and display the data through assignment of the static.

If you absolutely must use two forms that are both sourced to the same database, and there is a large possibility that both will display the same record at the same time, yes - you must either live with some record locking, or the programmer must control the advancing of either one of the two forms in relation to the other. There is no command in Sesame that will allow two (or more) points of data entry to write to the same record at the same time.