The reason for writing this article was the fall of the base during configuration saving, with dynamic updates. It seems to be how many times warned - "Do not make dynamic updates to 8.2" but sometimes, without it simply can not do.

So nothing no signs of trouble, but suddenly during the configuration save, 1C generated an error about the Config damaged and closed safely. Thinking that the problem will be solved very simply, I rediscovered the Configurator and read the following message:

"Warning !!! If you update the data after the last restructuring, an error occurred. Repeat the update?" "Well no"

Still staying in a joyful mood, I clicked on "Yes". 1C-ka little thought and issued a new message:

"Detected an incomplete configuration save operation. To continue, you must complete the operation."

After pressing "OK" the window closed with the configurator. It was then that I began to suspect that all is not so simple.

The first thing I got on mista and infostart looking for, if not solutions, at least to the causes of this problem, but nearly all were advised the same thing: "restores the database from a backup." Backup of course there was but one nuance - more than half of the day, 2000 users, make a bunch of documents and other useful work, and the backup was only as of the morning, and database recovery, larger than 100 GB, takes well oooochen long time.

Continuing to dig deeper, I came here to this great article VanDiesel1 . That's just this method does not work if the bases are located in different clusters, but a little thought, I still found the solution. After reading the article, I learned that the thing is "spoiled" and tables dbo.Config dbo.ConfigSave.

So, aside panic!

1. Check whether we have a configuration identical collapsed. In my case, there were as many as 4, as we work through the storage configuration. You can use and not quite the same configuration, but be prepared for the fact that when all changes have to pay again (unless of course you do not have the storage configuration).

2. Next, go into the SQL Management Studio and clear the table and dbo.Config dbo.ConfigSave base collapsed with the aid of a simple request (to send it, click "New Query" or "New Request", well, to perform - "Execute" and "Run", respectively):

Truncate table dbo.Config

Truncate table dbo.ConfigSave

3. All that now remains "fill" the same table from a good configuration. As I wrote above, the method proposed by VanDiesel1 not help me as a working base and all bases with good configurations are in different clusters. After reading the manual to SQL Management Studio, I stumbled upon this possibility as import tables from one database to another and immediately decided to use it. So in SQL Management Studio to become corrupted database and right click, then Tasks -> Import Data.

This opens a wizard in which:

• a) On the second page, specify the server and database from which we take data.
• b) In the third indicate the base receiver.
• c) In the fourth select "Copy data from a spreadsheet."
• d) In the fifth note jackdaws table dbo.Config and dbo.ConfigSave.
• e) On the sixth looking to avoid mistakes and loading process was successful.

4. That's all, you can try to run 1C.

PS In the course of finding a solution found that this method of recovery is undocumented 1C and all the actions you perform on your own risk, and documented way - is restoring from backup.

I hope this article helps someone to save time and nerves.