Change Storage
VCS Records
You can use Configuration packs to monitor changes in particular records.
Each action (create, delete, update) on a versioned table object leads to creation of a record in the VCS Records (sys_vcs_record) table. This table contains information about the changes done in any application on the platform.
All the changes are stored in the Default local pack unless another one exists and is selected in the Admin preferences menu, in the Local pack field. To know more, see Managing VCS records in the Assembling a Local Pack article.
It is also possible to import and preview the imported VSC records, see more in the Importing Configuration Packages article.
Protection Policy
The Protection Policy attribute is responsible for data protection purposes. After creating a record in the versioned table, the Protection Policy for this record is Open. Once the record is updated, the Protection Policy becomes Changed. These values are transferred to the Record Policy field in the related VCS record, that is, the record version has the same Policy as the record itself.
Admin can update only the Local Pack and Is Strong Overwrite fields of records with any protection policy.
During the importing process, the records possible to overwrite can be updated. Both record policy values set in the system and in the configuration pack are taken into account. All possible policy combinations are described in the table below.
Source record Protection Policy | Target record Protection Policy | Result |
---|
Protected
| Protected | Success |
Open | Success |
Changed | Success |
Changed
| Protected | Failed. Use Strong Overwrite to proceed. |
Open | Success |
Changed | Success |
Open
| Protected | Failed. Use Strong Overwrite to proceed. |
Open | Success |
Changed | Failed. Use Strong Overwrite to proceed. |
See the Development Recommendations article, to know more about the Record Policy.
Client Company Identification
To enable a client company identification, a client prefix should be set in the server settings. This prefix (if given) is added to the names of tables created by the client. This measure eliminates the confusion in case when a client creates a table with a name similar to one created by one of the applications. So the application prefix follows the client prefix. For example, there is a table Work Schedule, that exists in the Simple application (its prefix is sys_), and a client (whose prefix is client_) creates a table with the same name Work Schedule in the same application. As a result, the client's table name appears as sys_client_work_schedule.
The general table name pattern is:
To get a client prefix from a table name, use the ss.getTablePrefix() method in your scripts.