What Is Settings in Database Mode?

This section presents the drawbacks of saving settings in files.

The file-based settings mode described earlier presents certain drawbacks:

• administration can be bypassed by editing the runtime environment deployed on the user machine to replace the directories referenced by the CATReferenceSettingPath variable
• in a client/server environment, the CATUserSettingPath remains bound to the client machine. Consequently, there is no real guarantee that an end user can access personal user settings when logging onto another client. The Version 6 client relies currently on the capacity to access a common directory from any client machine (via an automount mechanism or roaming profiles). This assumption is only valid on a LAN.

This section presents the benefits of saving settings in the database.

The settings in database mode, as the name suggests, avoids these problems by saving settings to and retrieving settings from the database while providing several benefits:

• it establishes a strong link between settings customization and the P&O security model because settings are associated with the project referenced at logon time and not with a runtime environment.
• it merges the current settings functionalities, for example, hierarchical administration, lock management per attribute etc. with the new capabilities provided via tight integration into the PLM infrastructure
• it makes access to settings more secure
• it reduces the cost of deployment over a WAN.

This section presents local cache mechanism.

In settings in database mode, the CATReferenceSettingPath and CATUserSettingPath variables in your runtime environment are not taken into account.

Settings are stored in the database at the end of your session and, when you start a new session are retrieved from the database and stored in one of two locations:

• by default, in the cache directory used to store the image of your session generated by the Local Save mechanism. You can save a native app session without committing the modifications in the database. Saved data can be reloaded in a future session to resume the task on the data in the state in which the data were prior to the save. This is called the Local Save mechanism.
• or, if you want to deactivate the Local Save mechanism for any reason, in a directory referenced by the DSYSettingDir variable which you must in any case add to your runtime environment file. To deactivate this mechanism, you must declare the PLM_DeactivateLocalSave variable in the runtime environment file and set it to TRUE. Deactivating the Local Save mechanism has the effect of storing the settings in the location pointed to by the DSYSettingDir variable.

This section shows how settings stored in the database are linked to your current project.

Settings are stored in a cache structure comprising other directories which bear the names of the projects to which you connect at logon. When you log on using Version 6, you are prompted to select a security context. The security context references your current project.

The following illustration shows a typical project hierarchy and the corresponding administration and user settings in the case of a multi-level administration hierarchy:

When User 1 logs onto security context SC 1, User 1 is assigned Role 1 on project P4. Logging onto a specific project positions the user with respect to the overall project hierarchy, and consequently the overall settings hierarchy. User 1 then inherits the settings created by the administrator in the corresponding settings cache directory for project P4, as well as the user settings. At logon, the settings are transferred from the database to the local settings cache. When User 1 logs out, any modified user settings are stored in the database.

This section describes the settings cache structure.

The cache directory where the settings files are saved after being retrieved from the database has the following structure. This simple example illustrates the structure of a settings cache for a default installation comprising the Standard and Engineering projects, both on the same level. The structure of the cache is the same, irrespective of where it is stored:

As illustrated above, when an end user logs onto the Standard project, the settings will be created in a project settings directory named Standard, or in a project settings directory named Engineering if the end user logs onto the Engineering project.

All project settings directories are created at the same level in the settings cache directory. The hierarchy linking these directories together is retrieved from the database once the end user has connected to the database. The hierarchy information is stored in the .hierarchy files placed in each directory. A hierarchy file stores the list of the project's parents from the project itself to the root project.

This structure of the cache is user-specific; it supports only one user at a time. You should allow users to have their own settings cache (in their HOME directory typically).

The .lastEnv file in the root directory of the cache is used to store the name of the last successful login project.

Note also the presence of the usr and Adm directories:

• the usr directory contains the user's personal settings
• the Adm directory contains the settings set by the Administrator: how the administrator sets settings and the role of this directory are discussed later.

Warning: The structure of the cache is not guaranteed in the future. Do not modify it in any way.