>>Surely, tables will be opened in shared mode. Other things relate to interface design. The main question here is following: will your users like to edit the same record simultaneously. If answer is 'not': you have choice to use either pessimistic buffering or non-buffering, lock design. If answer is 'yes', then next question is coming: should users be aware of the changes another user makes to the same record in the same time. If answer is 'no', then use non-buffering, non-lock design. If answer is 'yes', use optimistic buffering.
>>You see, the good part of the job is to collect right user's opinion. From my experience, I would say that 90% of users don't like to edit the same record from different workstations, therefore I like non-buffering, lock design.
>
>Thanks Ed,
>
>I understand what you are saying but what I'm looking for is the following: In the load method, I am opening up the tables required, each one shared with an alias -----> when a user successfully saves a record the save method make changes to certain fields of the current record. Not all of these fields appear on the form (i.e. their values are changed programatically based upon what is entered in certain other fields) - so I use 'replace record1.tablealias with text' to make the changes. For all of the records in the table that have fields on the form, I set the controlsource property to the corresponding field and use tableupdate() to commit the changes.
>
>So, if two users are using 'tableA' (opened as shared table) - do they each have to open the table with a different alias ?

Not at all. Users will work with the same table/alias and buffering will handle multi-user collisions.