A note about multi-user database access.

Whenever an user packs a database, or changes the record structure (adding/modifying/deleting fields), a problem shapes up: other users accessing the same db could make disasters by writing incorrect information on the db itself. Examples:

  • A new field is added, or an old one gets deleted/modified by a remote user. Another remote user adds a new record, but since his/her instance of MaxBase didn't know about the changes in the db structure, they save a record with the wrong number of fields.
  • The db is packed by a remote user, and this means that the records don't have the same ID (absolute position in the archive, the parameter used in RXDbase modirec/delerec methods) they had before. Thus, another remote user could tell MaxBase to delete a record, which has not the same ID as before (the wrong record is deleted).

How are these issues handled?

MaxBase knows about these problems, and thus everytime someone makes a "significant" change to the db, an internal counter (token) is incremented. Everytime MaxBase accesses a server, it presents its version of the token before doing the transaction and/or is told what is the current token. Whenever a user tries to modify the information contained in the db with a non up-to-date token, the server refuses to do the transaction, and the MaxBase instance automatically updates information to be presented to the user, in accord with the new token (e.g. the fields will automatically change name/size/indexing in the running MaxBase instance). This is transparent both to the user and the developer (who uses RXDBClient and JRXDBClient).

The bottom line is: you can't harm the database by having more than one person working on it at once. (Bugs apart, that is)


Max Marsiglietti © 1997
Layout and artwork Andrea Resmini 1997