The default update mode is 'persistent'. In persistent mode, all changes to the database are written to the file system at the directory specified in the parameter '-d'. Persistent mode is suitable when a ConceptBase server runs for a longer period of time and is directly updated by application programs. Typically, the class and meta class level are then left unchanged though ConceptBase has in principal no restriction on this.
If the ConceptBase system is used for testing and modeling purposes, the update mode 'nonpersistent' is an interesting alternative. We describe two scenarios.
Scenario 1: Single-user Modeling. When a user needs to model a certain application domain with classes and meta classes, she usually works with external Telos files (aka source models, file extension '.sml'). These files can include comments like usual with program source code. The recommended mode here is '-u nonpersistent' without specifying a database. The user can load the source models into such a non-persistent server and make corrections to the source files in case of errors or design changes. Here, ConceptBase is mostly used to check and analyze the models.
Scenario 2: Assignments. Assume that a teacher wants students to exercise a certain modelling task using ConceptBase. Then, she would prepare some Telos files with necessary definitions (e.g. some meta classes) and load them into a persistent ConceptBase server. After that, she can restart the ConceptBase server in non-persistent mode on the same database created before. Student can then work on their extensions while the state of the database can easily be set back to the original state defined by the teacher. The module system of ConceptBase can be used to support multiple students to work on the same server without interfering with each other.
The second scenario might also be useful in modeling. If there are some parts that are regarded as stable, the modeller can decide to make them persistent and only add/modify those Telos models that are still subject to change. In particular for large Telos models, this strategy saves time.
If ConceptBase is used in a multi-user setting, then one can combine the update mode with the module feature (see section 5.1). In this scenario, multiple users access the same ConceptBase server. A common super module (e.g. the root module System) carries the common objects of the users. Each user can be assigned to her own hown module (a sub module of the common super module) and create and update objects in this workspace without interfering with other users. If several groups of users shall share their definitions, then they would be assigned to the same home module. The home module may have sub modules for testing and releasing definitions. By employing access rights to modules, one can also design which user has which read/write permissions. The 'save module' utility described in the ConceptBase Forum allows to save the contents of a module to a Telos source file.
It can be that your license key disables the features multi-user mode and/or persistency. The CBserver reports that in the shell/command window in which it is started. You can ask the ConceptBase team for an extended license key if you need these features.