After loading a .SOP file into a retrieved pack record or after merging several local packs, some VCS records can thrown some errors. For example, the translation records on the target instance are different from the ones in retrieved pack causing data inconsistency, or any other reason.
Generally, collisions may appear during the configuration pack import process. Their leading cause is that the dependent table or record does not exist in the database.
Consider a common use case:
You can find the erroneous record at the VCS Preview Log related list (in the VCS Retrieved Pack section). This record has the Collision state and the appropriate Error Text containing the error cause. Erroneous records cannot be included in the saved records pack (VCS Records) bound to the retrieved pack that is used for data recovery.
To resolve a collision, follow these steps:
Make necessary changes to the record in the JSON Copy field.
In some cases, especially when the version records need complex fixes, it is preferable to configure the erroneous records on the source instance. |
Please keep in mind that if any collisions occurred during the local pack preview, the process will be canceled on the first occasion, the others will not be shown. |
If you correct the records on the source instance using the JSON Copy field, make sure to export the created local pack as a new application to save all the changes. It is necessary for saving the right configuration pack. This allows further use of the pack without throwing errors on other instances. |
The idea in the collision fixing process is to try to dispose of collisions in the highest level tables.
Collision case 1When installing a configuration pack in the system, some record X is added. At the same time, it references to another record Y in this system and in this configuration pack. The Y record that the record X is referenced to does not exist. When the export admin previews the pack by clicking Preview Local Pack, the collision is thrown on this record. Collision solving: The solution is to add the Y record to this configuration pack on the source instance. |
Collision case 2The record X is deleted from the system. At the same time, there is a reference to this record in the configuration pack. When the export admin previews the pack by clicking Preview Local Pack, the collision is thrown on this record. Collision solving: The solution is to remove the X record from the configuration pack. |
Collision case 3Mismatch in the set of fields. Details:
Collision solving: Continue import with the Warning state. In this case, the column will not be created, the table will have the N-1 set of fields. |
Collision case 4The records on the target instance are newer than in a configuration pack to install. It can be determined by the date and time of record creation. Collision-causing records will be marked with the Skipped state. Collision solving:
|
Collision case 5In the configuration pack, a table is to be deleted but contains records (is not empty). Collision-causing records will be marked with the Skipped state. Collision solving:
|
Collision case 6A configuration pack contains objects related to the application X. The target instance does not have this application installed. Collision solving: The solution is to rebuild the configuration pack on the source instance in order to add records related to the missing application. |
Collision case 7Partial attributes mismatch between instances, that is, equal tables have difference in columns. Details:
Collision solving: Continue import with the Warning state. In this case, the title column will not be created, the source instance will keep the number column. |
Collision case 8The collision cause is a unique key violation. Details:
Collision solving: Select a more relevant (correct or up-to-date) translation record:
|