"Configuration structure integrity violated" error. Error "The integrity of the configuration structure is violated The integrity of the configuration structure is violated 8.2 how to fix

Usually the error occurs when there was a failure in the process of saving the configuration. As a result, the Configuration was saved incorrectly.

1. Try to check through testing and fixing or ChDBFl.exe
2. Look at the following solutions to the problem:

In some cases, clearing the CACHE completely helps. In Windows 7, there are C:\Users\Administrator\AppData\Roaming\1C\1Cv82 and C:\Users\Administrator\AppData\Local\1C\1Cv82 (Win7x64).

or in more detail:
1. A clean configuration of the same version is required - working.
2. Full cache cleanup (specified above).
3. Run a clean database in the configurator mode and open the configuration. At the same time, 1C creates its cache in C:\Users\Administrator\AppData\Local\1C\1Cv82 (a set of files and folders in a folder with a configuration ID.) We also need a cache C:\Users\Administrator\AppData\Roaming\1C \1Cv82. You can simply rename these folders after closing 1C.
4. We launch our non-working database in the configurator mode and look at the cache. And as a result, we have two folders with a configuration ID (Live and Dead).
5. We close everything and replace the cache of the dead conf with a live one completely. Those. delete the current one and replace it with the previously renamed folder.
6. We launch a non-working database in the configurator mode AND HERE is the first success - the configuration tree is open, the sections of the configuration management menu are active.
7. We go to support management, and remove from support completely. save, update. Can be updated via the working base configuration file.
8. Remove the cache completely.
9. We start a non-working database in the configurator mode, try to open the configuration - everything opens, there is no error.
10. We launch 1C. Everything is available. Data in place.

There was the same message when I dynamically updated the configuration of the central database and made an exchange for the peripheral one and a similar message appeared on the peripheral one.
1. Because I didn’t start up in the configurator on the peripheral at all, I had to delete the folder C:\Documents and Settings\Admin\Application Data\1C\1Cv81.
2. I went to the configurator and chose Configuration - Database configuration - Return to database configuration.
3. MasterNode installed undefined.
4. Configuration - Load configuration from file (central configuration).
5. MasterNode installed the required.

I had a similar situation, but on 8.1. During the dynamic update of the configuration, a failure apparently occurred, after which an attempt to unload both the Main conf and the DB conf, with a further attempt to upload the file to the local database, “the integrity of the configuration structure was violated” fell out. But the database is working. Neither testing and fixing nor ChDBFl.exe yielded anything.

I made a backup of the working database and uploaded it to a clean database. Added exchange plan
http://kb.mista.ru/article.php?id=7
and created the initial image. In the image database, the configuration has been corrected.

If it does not help, I can advise the option that I wanted to resort to myself:
1. find the nearest configuration release, load it into a clean database (recoverable).
2. create a completely clean database (intermediate)
3. open the configurator of the corrupted database.
4. copy-paste the modules and objects that have changed since the last release (in my case it is much easier, since the changes occurred only in modules and forms, the data structure remained the same and all changes are documented by posters) from the damaged database to the intermediate one.
5. Unload the intermediate configuration.
6. Merge it with the database being restored.
7. Unload the restored configuration to a file.
8. Load the configuration from the restored one into the corrupted database.

In theory, the maximum approximation to the working base should be obtained, but the work is certainly not easy. But it's still better than losing the entire base.

Another solution to the problem associated with corrupt provider configuration. When updating a configuration that is in editable support and the integrity of the vendor configuration is broken, the following message may appear:

My solution is to replace our database vendor configuration.
The sequence of actions is as follows:
1. Remove vendor configuration by removing support (Configuration->Support->Support Setup->Remove Support)
2. Create a configuration delivery file (Configuration->Configuration delivery->Create configuration delivery and update files). In this case, we will call the file work the delivery file.cf
3. We combine our configuration with the newly created delivery file (Configuration->Compare, merge with the configuration from the file). In this case, a proposal will appear again to put the configuration on support.
In the configuration comparison window that appears, click "Run",
4. Update the database configuration (Configuration->Update database configuration).
In theory, by performing these steps, we have restructured the provider configuration.
Now we can try to update our configuration to the next version in the normal way.

Today I will tell you about what actions to take if, after updating the 1C 8.2 configuration, the error “The integrity of the configuration structure has been violated” crashes.
So, to the point: you can try to solve the problem as follows (before starting any of the configuration actions, do not forget to make an archive copy of the database, as I wrote in a note about how to do this):

• Create a new empty database in a new folder and load into the configuration the previously uploaded infobase that needs to be updated.

If you use the option as a solution to the problem in principle, then the inconvenience lies in the fact that during multi-user work you will have to rewrite the paths to the database. We try to update this configuration and then run.

If the problem is fixed, then most likely it is necessary to clean the 1s cache folder ( C:\Documents and Settings\User\Local Settings\Application Data\1C\1Cv82). The folder will most likely be hidden by default, so if you do not know how to access hidden files and folders in windows, I recommend that you read the note. Files in the root folders 1Cv82 and 1Cv81 with the current/last modification date should not be touched. They store the settings of the start windows. Everything will start in this case too, but then you will have to wait at the first start.

After solving the problem (if, of course, the proposed method helps you), I recommend making an archive copy of the database again and checking the configuration for errors using the standard 1C Test and Fix tool.

Testing and fixing information security

You need to go to the configurator and in the menu item "Administration" select "Testing and fixing":

The tool works in 2 modes

• Testing is a mode that only checks for configuration errors.

• Testing and fixing - a mode in which both checking and correcting configuration errors are performed.

When the infobase is running in file version and work option client-server, it is possible to test and correct logical integrity, referential integrity and recalculation of totals. For the file version of the infobase, it is possible to re-index and compress the database.

For distributed infobases (DRIBs) from which it is possible to obtain data containing links to objects that are not in the tested infobase, clear the checkbox Checking the referential integrity of an infobase will allow disabling the creation of "non-existent" data and, as a result, will not lead to the transfer of this data to other nodes of the distributed infobase.

It is impossible to enable IS referential integrity checking by disabling logical integrity from checking. Also, disabling referential integrity check does not mean that link type checking is disabled.

The weakest point, for example, in Accounting, is the Balance Sheet, therefore, before and after processing, I recommend creating a turnover and comparing the totals before and after testing and correcting. This is certainly not the apogee of testing, but at least something.

That's all I wanted to tell you today. See you again.

Dynamic update failed. The program remained available to users in Enterprise mode, but the configurator stopped opening.

Initial data: 1C Enterprise 8.3, client-server database, MS SQL 2012, backup configured using MS SQL, backups are created once a day, at night.

The configuration has been modified and is being actively worked on, so I had a second server base in which development was carried out, plus there were uploads to dt from both bases for the previous day. The name of the working base in the article will be "MyBase", as the name of the standby server base "MyTestBase"/

In my case, the ConfigSave database table was empty, as in the described materials, and the Config and Params tables contained rows with the value "DynamicallyUpdated" in the FileName field

Materials from the network that I used to solve the problem:

The customer decided to carry out restoration work at the end of the working day with the risk of losing data for the current day (in case of failure of the restoration procedure and the need to roll back to a night backup).

To solve the problem, the following steps were taken:

1. Disabled all user sessions 1s

2. Through the management console 1 with servers, the blocking of the start of sessions and the cancellation of the launch of scheduled tasks are set.

3. A backup of the working database was made using MS SQL using SQL Server Management Studio. queries from tables

removed entries with "DynamicallyUpdated" values ​​in the FileName field from the Config and Params tables:

and
Delete From..
WHERE LIKE "Dynamically Updated"

4. Using the configurator, the last unloading.dt from the working database (the evening of the previous day) was loaded into the backup database and the last working configuration of the current day from the existing .cf file was loaded on top (the entire history of configuration changes is stored in separate files with version numbers)

5. In the task manager, I had to disable hanging processes 1s8

6. Stopped server service 1c

7. Cleared cache 1C

In my case, it was renaming the folders C:\Users\Administrator\AppData\Local\1C\1сv8

C:\Users\Administrator\AppData\Roaming\1C\1CEStart

C:\Users\Administrator\AppData\Roaming\1C\1Cv82

C:\Users\Administrator\AppData\Roaming\1C\1Cv8

8. Server service started

9. After cleaning the cache, the window with the list of databases is empty when starting 1C, so we add the existing working server database

10. The configurator opens. Just in case, we unload the working database into .dt in the current "broken" state and close the configurator

11. We start SQL Server Management Studio and use a query to clear the Config table in the working database and overwrite it with the contents of a similar table from the backup database:

Delete From..

INSERT INTO .. ​​SELECT * FROM ..

For the authors of the materials used (see links above), after the actions performed, the database was restored to working capacity. In my case, at the current stage, the error remained; it was not possible to open the database window in the configurator. Comparing the number of records in the Params tables of the working and backup databases, I came to the conclusion that it is worth trying to overwrite it too:

Delete From..

INSERT INTO .. ​​SELECT * FROM ..

After that, I managed to launch the configurator and open the configuration window. Unloaded just in case in the current state in .dt and loaded over the last working configuration of the current day.

12. Disable start session lock and enter in enterprise mode

Performance is fully restored, no data is lost.

13. Turn off blocking the launch of scheduled tasks.

One of the many solutions to the "Configuration Structure Integrity Violated" error.
If you happen to encounter this error, contact a 1C specialist unambiguously. There are many solutions, but depending on the situation and the source of the problem, the solutions are completely different.

I bring to your attention one of such situations.
Task description:
The configuration update happened automatically. When starting the 1C configurator mode, we get the message "The integrity of the configuration structure has been violated." During auto-update, the vendor configuration could not be updated correctly. Running in user mode throws an error referring to a module in the configuration.
First, you need to clear the cache. On Windows 7, C:\Users\Administrator\AppData\Roaming\1C\1Cv82 and C:\Users\Administrator\AppData\Local\1C\1Cv82 (Win7x64) are located. After clearing the cache, 1C will start in configurator mode. When you try to open the configuration 1C crashes. Upload the infobase to a backup file. Testing and fixing doesn't help. The file base check utility says that there are no errors. Menu items for loading, unloading configuration, support, etc. without an open configuration are not active. Saving the data configuration is available - this means that the data is not destroyed, which is the main thing..
Also, from the configurator to the user mode in debug mode, it may start, or maybe not, this does not affect the situation.
An attempt to load the infobase into SQL will not lead to a positive result.

And then the thought arises that it would be possible to put an end to the base ... to rise from the ancient backup, if there is one ... and strain with manual data recovery.

Solution:
1. A clean configuration of the same version is required - working.
2. Full cache cleanup (specified above).
3. Run a clean database in the configurator mode and open the configuration. At the same time, 1C creates its cache in C:\Users\Administrator\AppData\Local\1C\1Cv82 (a set of files and folders in a folder with a configuration ID.) We also need a cache C:\Users\Administrator\AppData\Roaming\1C \1Cv82. You can simply rename these folders after closing 1C.
4. We launch our non-working database in the configurator mode and look at the cache. And as a result, we have two folders with a configuration ID (Live and Dead).
5. We close everything and replace the cache of the dead conf with a live one completely. Those. delete the current one and replace it with the previously renamed folder.
6. We launch a non-working database in the configurator mode AND HERE is the first success - the configuration tree is open, the sections of the configuration management menu are active.
7. We go to support management, and remove from support completely. save, update. Can be updated via the working base configuration file.
8. Remove the cache completely.
9. We start a non-working database in the configurator mode, we try to open the configuration - everything opens, there is no error.
10. We launch 1C. Everything is available. Data in place.

Here is another rescue option suggested by infostar user Tavalik:

1. "Configuration" - "Database configuration" - "Return to database configuration"
2. "Configuration" - "Update database configuration"