Yes, Qual 10 is set as default because it is always "faster" than Qual 2. Qual 2
is an option to help reduce (not prevent) the number of data lock conflicts that might arise in a heavy multi user environment where updating is concerned. (Data lookups are not effected by either Qual 10 or Qual 2 as no locks are involved.) So Qual 2 only is for reducing locking conflicts in a multiuser environment during update commands. For the second question, I do not believe the StaticDB or FastLock had any effect on your hang up. Staticdb is related to changing database structure which your update did not do and FastLock is a speed setting. The hang would have been caused by your Edit form having set a lock on a table and then your update could not complete due to that. If your update effected every row in the table, then it would not have mattered if your QUAL was set to 10 or 2. Whenever your update hit the record being locked by the open form, it could not have updated. There is a setting to set how long to wait for a retry, but I am unsure what you have set there. So to answer your question..... I can't! If you mean by multi row update, that not all rows were being updated, then your QUAL 2 setting would have had less of a chance of locking a record in your update, but not guaranteed! Your QUAL 10 setting would have locked more records, thus increasing the chance of a conflict, but again not guaranteed. If you mean by multi-row update, you mean all records, then it did not matter which setting you used, as you would have had a conflict regardless. In this case the WAIT and INTERVAL settings would possibly have been more relevant. However, if the user edited a record and walked away from the PC for a long period, nothing would have cured that issue. -Bob ----- Original Message ----- From: [email protected] To: "RBASE-L Mailing List" <[email protected]> Sent: Wednesday, November 4, 2009 9:49:38 AM GMT -06:00 US/Canada Central Subject: [RBASE-L] - Re: Qualcols 2 vs 10, what do yougiveupbychangingfrom 2 to 10? 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 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
