Hello,
I have an application that several people should be able to access at the same time to enter and modify data. After several attempts at buffering in various modes, and not really satisfied with results, I decided to go the longer way. The form used to enter data uses some dummy table in its Data Environment that grids and other control elements can reference at design time as real. The top-level form, though, creates a cursor:
SELECT * FROM real_table INTO CURSOR dummy_table READWRITE WHERE <condition>
before calling the data form (where "Data Session" is set to "1 - Default Data Session", so the form doesn't look for a table if a cursor with the same name already exists); "dummy_table" is the same name that the data form uses. The idea is that the user doesn't work with real data at all, but only with its CURSOR phantom, only interacting with the real table when he decides to confirm entered data - some simulated imitation of optimistic table buffering without actually locking the table at all. In fact, the table with the "dummy_table" name doesn't even physically exist in the common area - I only keep an instance of it on my own computer to be able to edit the form when a need arises. Since each user normally works with his own segment of records, interferences are rare and can be handled easily. And since the user doesn't touch the real table except for short data exchange bursts, there's no chance for access conflicts. Right? Right?
In reality, though, this is not so. Every once in a while I witness the error message #109: "Record is in use by another user" after editing a field in the grid that *only* has references to the table that exists in its CURSOR incarnation and never as a real thing. What could be possibly a reason for such behavior?
Thanks.
I have an application that several people should be able to access at the same time to enter and modify data. After several attempts at buffering in various modes, and not really satisfied with results, I decided to go the longer way. The form used to enter data uses some dummy table in its Data Environment that grids and other control elements can reference at design time as real. The top-level form, though, creates a cursor:
SELECT * FROM real_table INTO CURSOR dummy_table READWRITE WHERE <condition>
before calling the data form (where "Data Session" is set to "1 - Default Data Session", so the form doesn't look for a table if a cursor with the same name already exists); "dummy_table" is the same name that the data form uses. The idea is that the user doesn't work with real data at all, but only with its CURSOR phantom, only interacting with the real table when he decides to confirm entered data - some simulated imitation of optimistic table buffering without actually locking the table at all. In fact, the table with the "dummy_table" name doesn't even physically exist in the common area - I only keep an instance of it on my own computer to be able to edit the form when a need arises. Since each user normally works with his own segment of records, interferences are rare and can be handled easily. And since the user doesn't touch the real table except for short data exchange bursts, there's no chance for access conflicts. Right? Right?
In reality, though, this is not so. Every once in a while I witness the error message #109: "Record is in use by another user" after editing a field in the grid that *only* has references to the table that exists in its CURSOR incarnation and never as a real thing. What could be possibly a reason for such behavior?
Thanks.