>Hi Nadya,
>
>>Put a table in buffered mode (5) on a form. Open another table non-buffered shared noupdate. Make a relation from first main table into this one. Put a grid on the form. Put one field from related table into this grid (other fields from the "main" table). Run two instances of the form (we did this on two different machines). Both tables are on the network, as well as the form. Choose the same record in both forms instances. Change field on one grid (don't move from this field) and try to change another field on another instance (same record). You would not be able to do so (record would be locked).
>
>Ähhm.. yes. If I am reading this right, this behaviour is by design <g>.
>If You edit a field .... Ahh no, it's buffered.
>
>I guess it's because of the relation to the non-buffered. Did You try to buffer the
>other one too?

We made this discovery at 7:10PM and we both were extremely tired, so I didn't try any workaround yet. My first idea was similar to yours - use the related table in buffered mode. Another idea would be to create a cursor, append from the second table (second table has only 6 records) and use cursor instead.

And final idea would be to switch to a view. This idea has lots of benefits (for instance, we're currently using filters and if we have 15000 recs and need to filter only 65 recs, the form responds very slowly), but this idea also would require lots of changes and not only in my own application, but in our framework as well...


As You're not updating it, it would not make a difference and to be sure
>You could tablerevert() at the end. I also would open it in updateable mode (needed for
>the tablerevert() anyway) and make the columns that You do not want to be updated RO as
>well as the columns' textboxes.
>
>How about working with a view? That way You could get rid of the relation. Make the lookup-
>fields non-updatable and You should be set. You could create it on the fly (in a dummy-database
>if You like) and destroy it afterwards.

Thanks again for your help, very appreciate your time spent on it. Now, since we found the cause of the problem, it would be easier to find a workaround. The only problem is that I use related table technique in bunch of my applications, so I would have to fix them all...