The mechanism and the configuration repository mechanism imply that configuration changes are made according to certain rules. Compliance with these rules ensures that the configuration will work properly in the future.
The mechanism for and loading them from .cf files takes into account the necessity to comply with these rules. If you saved the configuration and changed it in another infobase, you may not always be able to "just" load it back into the original infobase. In some situations, the platform will ask you to unlock objects of the original configuration if it is supported or bound to a repository.
When you deal with a .cf configuration file, you should change it using the means of 1С:Enterprise. But, as you know, the platform has another mechanism that allows you to make configuration changes without using the platform. This is the mechanism for and restoring configurations from XML files.
Development of this mechanism brought about potential configuration changes to bypass the rules required to support the configuration or repository operation. Such changes may lead to a malfunction of the configuration.
For example, the configuration is fully supported and updated automatically. After restoring from XML files, it will continue to be fully supported but will be different from the vendor configuration. Then the first automatic update will cause changes introduced through XML file editing to be removed.
Another example illustrates the situation when the configuration is bound to a repository. As a result of the configuration being restored from XML files, objects that are not locked in the repository will be restored and changed. When you update the database configuration, these changes will be included in the database. However, next time one of such objects is locked in the repository, the changes that were restored from XML files will be lost. This is due to the fact that during locking, Designer gets the latest version of the object from the repository. Thus, if when restored from XML files, some objects were added, they will be deleted when a parent object is locked.
In order to avoid such situations and make the platform operation more uniform, we have introduced a number of restrictions on restoring configurations from XML files. These restrictions apply to three situations.
Restoring into a configuration connected to a repository
- Full restoration is not possible.
- Partial restoration is possible only when all of the objects that will change after the restoration are locked in the repository.
- Full restoration is possible only when all the target configuration objects are editable.
- Partial restoration is possible only when all the target configuration objects that will change after the restoration are editable.
If the XML dump includes support settings (file ParentConfigurations.xml):
- Full restoration is not possible;
- Partial restoration is not possible when the root object of the configuration is restored (file Configuration.xml).
In order to be able to restore this configuration, you must delete the support settings file from the dump directory. If dumping was performed in a flat format, this file is Configuration.ParentConfigurations. And if dumping was performed in a hierarchical format, this file is Configuration.ParentConfigurations .bin.
As a result, the configuration will be restored without the support. You must also realize that all the information about the support settings will be lost. You will not be able to use it in the future.
