R:BASE has always offered an excellent multi-user interface built upon flexible database and table-locking schemes, including concurrency control for data entry and editing. The concurrency control, locking, and resource waiting essentially prevents two users from modifying the same data at the same time. Concurrency control, row, table, and database locks only affect operations in which users are storing new data or altering existing data. R:BASE allows as much access to database resources as possible and keeps the duration of locking as brief as possible. However, the extent to which users are locked out of resources depends on the operations that cause R:BASE to issue the locks.
Concurrency Control
The most effective feature for data entry and editing is concurrency control. This automatic feature allows any number of users, using either forms or the EDIT command, to enter and edit data at the same time in one table or in many tables. Concurrency control takes advantage of the computer's speed to check whether the data user1 is manually modifying has been changed by someone else since user1 selected it. This leaves the control of change to the data in the hands of the last person who edits it. Concurrency control gives access of a particular row of data to several users, not limiting access to a table or a row of data to one user at a time. When the row of data is finally saved to the table, R:BASE does a quick table lock. This is to prevent other users from making structural changes.
Resource Waiting
When a command has been locked out of a resource--database, table, column--R:BASE checks to see if the requested resource is available while in the waiting period. If the resource becomes available, the user can proceed. If not, R:BASE displays a message informing the user that the resource is unavailable, ignores the command, and goes on to the next command.
When establishing the database and application in a multi-user environment, there are concurrency setting considerations to make. The following are the R:BASE concurrency settings, their values, and how the values can be applied. Each setting name can be selected to review their affect upon the application in a multi-user environment. You may need to change multiple settings to have the desired effect.
Setting |
||||||||
Code Location |
Before CONNECT |
Before or after CONNECT |
||||||
Default |
ON |
ON |
OFF |
ON |
ON |
COLUMN |
4 |
5 |
Value Options |
ON|OFF |
ON|OFF |
ON|OFF |
ON|OFF |
ON|OFF |
ROW| COLUMN |
0-16383 seconds |
0-9 tenths second |
Required for all |
YES |
YES |
NO* |
NO |
NO |
NO |
NO |
NO |
Optional for all |
NO |
NO |
YES* |
YES |
YES |
YES |
YES |
YES |
Requires prior setting of |
|
MULTI ON |
STATICDB ON |
|
|
|
|
|
Enabled before CONNECT |
YES |
YES |
YES |
NO |
NO |
NO |
NO |
NO |
Optionally made before/after CONNECT |
NO |
NO |
NO |
YES |
YES |
YES |
YES |
YES |
Same value for all users |
YES |
YES |
YES |
NO |
NO |
NO |
NO |
NO |
Different value for users |
NO |
NO |
NO |
YES |
YES |
YES |
YES |
YES |
Set once per user |
YES |
YES |
YES |
NO |
NO |
NO |
NO |
NO |
May change per user |
NO |
NO |
NO |
YES |
YES |
YES |
YES |
YES |
* While ideal in multi-user operations, FASTLOCK is not required. However, if one user is connected to a database with FASTLOCK ON, all must do so as well.
The settings may be set within the R:BASE configuration file. However, the settings are best set in a startup file before connecting to the database. For example:
DISCONNECT
SET MULTI ON
SET STATICDB ON
SET FASTLOCK ON
SET PAGELOCK OFF
SET ROWLOCKS ON
SET VERIFY COLUMN
SET WAIT 4
SET INTERVAL 5
CONNECT ConComp
Related Topics:
Schema Reading Mode with SET STATICDB
Using SET ROWLOCKS to Lock Rows
Effects of the SET WAIT Command
Control Row Locks with SET PAGELOCK
Reduce Data Conflicts between Users with SET VERIFY
Other Multi-User Considerations
