Marc, After screwing around, we developed a simple solution. I am sure there is a much more elegant solution, but this worked great. Add an integer column (ID_Open) to a table (Info) that will track when someone is editing a particular row. Field default is 0 which means no one is there. 1 means someone is editing that row. Use UPDATE to change ID_Open for that row. Something like this in a menu Bit Button EEP does the trick and is easy to move to other buttons. :
--Check to see if the row is available to be edited SET VAR vID_X INTEGER = ID_Open IN Info WHERE ID = (.vID) -- It is available IF vID_X = 0 THEN -- Change ID_Open to 1 so no one else can edit the row while you are there UPDATE Info SET ID_Open = 1 WHERE ID = (.vID) EDIT USING ID_Edit WHERE ID = (.vID) -- You are done editing. Change ID_Open back to 0 so this row is available to whoever comes next UPDATE Info SET ZED_ID_Open = 0 WHERE ID = (.vID) ENDIF -- It is not available. IF vID_X = 1 THEN --Run form that basically says someone is editing this form, come back later EDIT USING Form_Used ENDIF Once we got this running it was pretty easy to add last edit date/time, last editor, current editor. This saved some real grief I got when someone's two paragraph masterpiece about an event (which took 10 minutes to write) was overwritten by a 3 word note (about 10 seconds) following a refresh because the second person saved their note before the masterpiece was saved. By using this ID_Open concept, the masterpiece is saved, the second writer can still add their 3 word note when they get access, nothing is lost (so far), and I can find who that second person was if the masterpiece writer is upset by someone changing their words. Once people figured this out, it seems editing became a little more careful, some petty stuff just ended, and my grief reception ratio dropped. We are now looking at this concept for other ideas such as permanent locks for selected people. Tom Frederick Elm City Center 1314 W Walnut Jacksonville, IL 62650 Off - 217-245-9504 Fax - 217-245-2350 Email - [EMAIL PROTECTED] Web - www.elmcity.org ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Marc Sent: Wednesday, July 02, 2008 8:49 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Multi users updating the same fields Hi Tom I don't have much experience with multi user apps but I just did a simple test and I think I could have the same problem Razzak has a FTE article about speeding up multi user apps that may help. Please let me know what you find out so I can check my app too. Marc ----- Original Message ----- From: Tom Frederick <mailto:[EMAIL PROTECTED]> To: RBASE-L Mailing List <mailto:[email protected]> Sent: Tuesday, July 01, 2008 1:57 PM Subject: [RBASE-L] - Multi users updating the same fields Playing with a small network (two computers) while doing side by side comparisons to find problems before putting the database into general use. The forms all have a SAVE button to save and an EXIT button which saves and exits. When more than one user accesses the same database, at the same field, we are not seeing a notice telling the other users that a field is being updated. Example: 1. ID info for Bozo says he has "red hair and very large feet" in a DB Memo field. This comes up on both comps at startup. 2. User 1 adds "He has a very large nose." and saves the info. 3. The screen info on User 2 does not refresh with this new info because Auto refresh defaults at 0. 4. User 2 saves after making edits on other fields on the same form, not knowing there have been changes by User 1 to the DB Memo field on another computer. 5. Checking the table shows that original message and the nose message added by User 1 was overwritten by the message from User 2's screen that did not include the nose message because User 2 saved second. 6. When auto refresh is set at anything but 0, changes made before the refresh are lost unless you are real quick with saving. What is the correct method of notifying multiple users who are updating/editing the same fields so simultaneous changes are shared and not lost? Is there a "best" autorefresh figure? Drop downs and other fields seem to work well. Several other forms have large text fields where concurrency and autorefresh can be a huge problem. Of course all the forms works great in single mode. Using V8 with the 60630 updates on both comps. Tom Frederick Elm City Center 1314 W Walnut Jacksonville, IL 62650 Off - 217-245-9504 Fax - 217-245-2350 Email - [EMAIL PROTECTED] Web - www.elmcity.org
