Ran into the exact same issue of two/more users, same form, same row, same time. Got around it by first person to the row locks out everyone by an EEP changing an access column (ActAdd) from 0 to 1. Also records who you are and when you were there. If I try to get in, a message says the row is locked and IDs the person who is there so they can be tracked down if needed. On exit, the ActAdd changes to 0 and anyone can access the row. Started doing this because people would write several paragraphs in a note, taking 4-5 minutes each, and stomp over each other when refreshes kicked in. The EEP row lock fixed that. All other user updates are very small. Big stuff is handled off hours.
Tom Frederick Elm City Center 1314 W Walnut Jacksonville, IL 62650 O - 217-245-9504 F- 217-245-2350 Email - [email protected] ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, November 04, 2009 3:42 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Qualcols 2 vs 10, what do Mike, You should review the WAIT and INTERVAL settings. These settings allow you to address common multiuser record conflicts that happen during the course of normal processing. I.E. user 1 locks a record for a few seconds and then moves on...i.e. unlocks it. The WAIT setting allows you to set a time period of how long RBase will wait for the locked record to "be freed up" before it aborts the update command. These commands will do what you mention below "automatically". BUT... are intended only for short record lock time intervals. INTERVAL is how long RBASE waits until it retries the command that ran into the record conflict. If a record is only locked for a short period of time, Rbase WAIT and INTERVAL settings handle this very nicely. Neither of these will resolve the issue of a user locking a record...(edit using a form etc.) and then going to lunch. To solve that issue, you have to approach editing entirely different. For example: Load the record into a temp table for the editing user. Have a date/time stamp on the permanent record. Whenever an update is saved, update the date/time stamp. When user1 opens an edit form and then leaves for lunch, they have a temp table open, not the permanent table. Thus no one is locked out. When they come back from lunch and finally save thier data, the save function reads the current permanent table's date/time stamp and compares to the one in the user's temp table. If it does not match, then someone else has made an edit while the user was out to lunch. Have your form respond back as such etc., showing the updated dated for example. (There are other ways to handle this logic as well.) More programming to be sure, but more "bullet proof" as well. So to recap... two users using a form to edit data, with the edit only lasting a short period of time, RBase will handle pretty much automatically. User 1 makes an edit, user 2 makes an edit at the same time on the same record. Who ever saves the record last, Rbase will notify that user automatically. Not much needs to be done here. This concurrency control mentioned above only works within forms however. If you issue a major UPDATE on numerous rows in some command file, then you have to keep user locks in mind when programming. Concurrency control in these types of UPDATES are not automatic, only in forms. Hope that helps. -Bob ----- Original Message ----- From: "Michael J. Sinclair" <[email protected]> To: "RBASE-L Mailing List" <[email protected]> Sent: Wednesday, November 4, 2009 11:34:51 AM GMT -06:00 US/Canada Central Subject: [RBASE-L] - Re: Qualcols 2 vs 10, what do yougiveupbychangingfrom 2 to 10? Karen, Your concern is exactly the same as mine. In the multi user environment, I have been getting some hang ups, and I want to minimize them. I suppose I could solve the problem by creating some entry in a table at the time any user is doing an update that would alert all other users that they will have to wait a moment and then retry to save their data. But if I can use the power of Rbase to solve the probem for me, I would prefer it. Mike -------------- Original message from [email protected]: -------------- Bob: Your explanation sounded very straightforward to me. So if someone is running with the default, it isn't SPEED that's necessarily the issue. It's resource conflicts. Is that what you're saying? I had the following problem at a client just yesterday. A user had an edit form up and I didn't know it. I was running a program that was doing a multi-row update on that table. Don't know if it would have updated that particular record, don't know if that record would have been on the same "page" as my big update. The update appeared to hang. Kicking her out made the update work. Assuming that my staticdb and fastlock were both set to ON (they are not at this client), what would I have set my qualcols to in each program? Karen I may be incorrect, but my understanding is that in a heavy multi user environment, if you have QualCols set to 10 you might be seeing a lot of "resources not available" conflicts. I.E. user 1 does an update and locks up an entire page of data instead of just the one row being updated. Anyone else accessing the database and happens to select a row in the same page that user 1 has locked will not have access until user 1 releases it. QualCols 2 would be that user 1 locks only one record thus user 2 would not get locked out unless they access the exact same record. So if your app is unlikely to access the same "page" of data for updating, even in a heavy multi user environement, then QualCols 10 would be OK. If your app is constantly updating the same table and likely records that are in like pages, then QualCols 2 would reduce the number of access conflicts greatly. So it all depends on what your app is doing. If only performing looks ups and entering new data 95% of the time, then QualCols 10 is probably the way to go. If a large number of users are accessing the same data for updates, the QualCols 2 probably is the way to go. As Razzak mentioned, this can be set "on the fly". However, I must assume that the effect is global. I.E. is user 1 sets QualCols to 10 and does an update, they will lock out pages of data. Even if user 2 has QualCols 2 (locks single rows) if they try to access data that is in the page of user 1, they will be locked out until the user 1 update completes. So with all things programming, one must evaluate the environment the app (or command) is going to be used. A scheduled command that runs at 2:00am with no one else on the system could/should have different settings than one running at 10:00am when a hundred users are connected. An app that is 95% new data entry or lookup would have different settings than an app that is 95% data maintenance. The QualCols in my opinion is a switch that is available for fine tuning. An update on a single record that uses an index column and a where clause will not have any speed difference if QualCols is set to 10 or 2. An update on 100,000 records without a where clause will have a magnitude difference. So again, it depends on what your app is doing. Hope that helps. -Bob
