Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Change
Storagestorage and VCS
Recordsrecords
All the changes are stored as VCS records in the VCS Records (sys_vcs_record) table. They are created automatically and cannot be deleted or edited.
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.
| Note |
|---|
Remember:
|
VCS Record form fields
| Field | Description | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Table name | The system name of the target record table. | |||||||||
| Record | The unique ID of the source record processed by the transaction. | |||||||||
| Document record | A reference to the target record for which the current VCS record is created. | |||||||||
| JSON copy | This field stores target record attributes in JSON format as an associative array.
| |||||||||
| Is current | This checkbox is selected if the version is current. | |||||||||
| Created by | The user who did the change. | |||||||||
| Created at | The date and time of the record creation. | |||||||||
| Local pack | The local pack that contains this record. | |||||||||
| Retrieved pack | The Retrieved pack to which this record is related to. | |||||||||
| Restored by | A unique ID of the version record from which the current record was restored. | |||||||||
| Action | Action type. Available options:
| |||||||||
| Record policy | Current record protection policy after the transaction is over. Available options:
| |||||||||
| Is strong overwrite | When the checkbox is selected, the current record will be written over the existing version with the Protected policy. |
All the changes are stored in the Default local pack unless another one exists and is selected in the Local pack field of the Admin preferences menu, in the Local pack field. To know . You can also set the local pack as current on the form of that pack. To learn more, see Managing VCS recordsin theAssembling a Local Pack Packsarticle.
It is also possible The VCS records can also be imported from another instance. See the Importing Configuration Packages article to learn how to import and preview the imported VSC records, see more in the Importing Configuration Packages article.
Protection
Policypolicy
The Protection Policy policy attribute is responsible for data protection purposes. After creating a new record is created in the a versioned table, the Protection Policy for this record is its Protection policy is set to Open. Once the record is updated, the Protection Policy becomes field value becomes Changed. These values are transferred to the Record Policypolicy field in the related VCS record, that is, the record version has the same Policy as the record itself.
Admin can only update only the the Local Packpack and Is Strong Overwritestrong overwrite fields of the records with any protection policy.
During the importing process, the records possible to overwrite can that can be overwritten, can also 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 Recommendationsarticle, to know more about the Record Policy.
Client
Company Identificationcompany identification
To enable a client company identification when the update is implemented, a vendor sets a client prefix should be set in the server settingson the instance. 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 the one created by one of the applicationsexisting in the application by default. 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:
| Infocode |
|---|
applicationPrefix_clientPrefix_tableName |
To get a client prefix from a table name, use the ss.getTablePrefix()method in your scripts.
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|