The configuration of the IB node does not match the expected

This error is typical for. The error "Configuration of a node distributed IB does not match the expected" is systemic. Basically arises due to an emergency completion of work during the exchange of data on URIB.

It is possible to solve this in a fairly simple way. Consider it.

Instruction

1. Make copies of the databases that work will be performed (in the Administration configurator - unload information base).

2. Run the main base configurator of the RIB node.

3. Save the central node configuration to the database file ("Configuration - Save configuration to a file ...")

4. Open the subordinate node base configurator.

Get 267 video tutorials for 1C for free:

5. Remove the configuration of the subordinate node with support (Configuration - Support - Support Settings - Remove from Support):

6. Load the database configuration ("Configuration - download a configuration from the file ...").

8. After restructuring, it is necessary to enter the enterprise mode and set the main configuration node. It is possible to do this with the help of special processing. Processing works both in the controlled application mode and in the normal application mode.

9. In processing, you must select the main node and click "Run":

10. Ready! Try starting the exchange, the system must correctly exchange.

• The message file has already loaded into the receiver's database. It is necessary to unload it from the source database.

Error "Error when copying a file with FTP resource ... Internet work error: Timeout Was Reached"

• From the site through which the exchange passes, it is impossible to copy the desired file. This may be due to the slow work of your Internet or with the problems of the site itself.
• You need to try to repeat the exchange after 15-30 minutes.

Error "Editing these periods is prohibited. Changes cannot be recorded ... "

• Downloadable data contains documents from a closed period.
• It is necessary to exchange under users who have the right to change the documents in this period.

Error "You must update the database configuration. Update can be performed in configurator mode »

Cause: Programmers changed the configuration in the center. Solution: Update the modified configuration in the peripheral database. For this:

• Go to the configurator.
• Run the menu item "Configurator / Update database configuration".
• If a question is issued with answers only "Repeat", "Cancel", "Update Dynamic", click the "Update Dynamic" button.
• If a question is issued with answers only "Repeat" and "Cancel".
  • all users get out of 1C.
  • press the "Repeat" button.
• For the remaining questions to answer the affirmative: "Yes," "accept", "OK".
• Close the configurator.
• Repeat download from the center.

The error "Configuration does not match the expected", "Attempt to receive changes from an unknown configuration"

• Error in the database.
• It is necessary to refer to the specialists.

Exchange passes very long, hangs

Possible reasons:

• There is a lot of data.
  • Find out from the sender, whether he performed a group change in documents (conducting, replacement of props, etc.).
  • If yes, leave a computer with exchange for the night.
• A large file cannot be gone from the Internet.
  • If the file has a large size (80-100 MB and more), then maybe 1C simply cannot download it.
  • You need to download the file and download it in 1C manually (maybe with the help of specialists).
    • operations menu item / exchange plans / full / button on the "Read message" panel.
• The base is damaged:
  • Try
• If these actions did not help - you will have to refer to those skilled in the art.

• If you failed to correct the error, call emergency support +7 (8512) 64-55-05.
• Our specialist will help you in any city you are not.

To begin with, I bring a list of reductions used by me:

• Rib - distributed information base
• CB - Central base, Rib root knot
• UB - remote base, database of remote node Rib

According to your own experience, I can say that I came across two reasons for an error:

1. during the reception of the message file in UB "fell" base, in connection with which, apparently, there was a disinxcline of conf. Central Bank and UB;
2. under MSSQL, the client has downloaded a copy of the working base and did not turn off the regulation in the copy. Autobractions assignments, as a result, part of the messages to remote nodes were formed from the working database, and a part of the copy, which led to the connection to the configuration

There is also the opinion that this error provides the use of a dynamic update mechanism. There are doubts here, because on the one hand, the dynamic update never affects the structure of the database, and the Rib mechanisms are still working precisely with the database structure, and not with its own part, nevertheless, the RIB uses a digital signature mechanism for the configuration version (in I will be called it to reduce Hashe), and when changing the applied part, the hash is naturally obliged to recalculate. I will not deny it nor say, because If I came across this situation, I did not find this evidence.

For correction I use 2 techniques, depending on the situation.

First technique

The first (the most common) is repeatedly mentioned in the affiliate conference, and on other Internet resources associated with 1C. It is used in most cases when despite the message about the configurations, when compared manually, it is issued that they are identical.

Sequencing:

1. unload the CF file from the Central Bank;
2. we asslaunt the UB from Rib (the method of installing chain, ready-made processing can be found in the appendix or in other publications);
3. replace conf. UB on the CF file unloaded in the first step, to do this, use the "Download configuration from the file" menu (and not comparing-association !!!);
4. relative signs of Rib for UB.

In most cases, these actions are more than enough that restore the exchange, but not always ...

Second technique

It is used if the first technique did not work, and it is not possible to unload the node again.

Prehistory: The client had a cascade rib and the error occurred in the first level of the stage (the second level all this time worked flawlessly). The configuration development was carried out in conjunction with the IT client service and from the moment the error occurs, the CB configuration managed to change several times. An option with a rollback of changes was not considered even in principle, because Loss of data parts and stopping the work of several units were completely unacceptable. The first version of the correction of the error of any tangible results did not give. In this connection, what had to look for other solutions.

A thought has come to try to replace hashi configuration files directly in the XML exchange files. Description of the sharing file structure from the book "Professional development in System 1C: Enterprise 8" gave a weak understanding of the formation of digital configuration signatures and changes in them, but determined the search direction: Digest1 and Digest2 values. Everything else found out a purely empirical way (I mean by the method of samples and errors), but the regularity is to establish the same.

Test experiments were successful. On the working bases, too, everything went well.

So, the sequence of actions:

1. perform actions 1 - 4 of the first technique;
2. unload from UB file sharing, but do not load it in the Central Bank;
3. unload from the Central Bank the exchange file, but do not load it in the UB;
4. in the exchange file from the Central Bank, we replace a block containing information about configuration changes and hashi (Digest1 and Digest2), on the cache block from the UB file (see example below)
5. we produce the file download from the 4th point in the UB;
6. be sure to overwrite the exchange file from the UB (2nd item)! This file should not be downloaded when exchanging in the Central Bank!
7. for verification, we make several consecutive exchanges.

If the exchange is used to compress data, then either turn off the compression, or first unpack the file, change, then we are reversed back and send.

File sharing unit from the Central Bank

106.0
... Here are the blocks for describing configuration changes ...
1CF680807E97A5DC0D1ED7F901B07392.
038211651CF680807E97A5DC0D1ED7F9.

you need to replace the exchange file from the UB (note the Digest1 from the file from the UB is always equal to "0000000000000000000000000000" !!!)

106.0
00000000000000000000000000000000
11651CF680807E97A5DC0D1ED7F901B0.

The listed actions must be carried out with marginal caution, the incorrect sequence is fraught with the complete inoperability of Rib. Therefore, before these actions, the creation of backup copies is required!

For the rest, I can only wish good luck!

To begin with, I bring a list of reductions used by me:

• Rib - distributed information base
• CB - Central base, Rib root knot
• UB - remote base, database of remote node Rib

According to your own experience, I can say that I came across two reasons for an error:

1. during the reception of the message file in UB "fell" base, in connection with which, apparently, there was a disinxcline of conf. Central Bank and UB;
2. under MSSQL, the client has downloaded a copy of the working base and did not turn off the regulation in the copy. Autobractions assignments, as a result, part of the messages to remote nodes were formed from the working database, and a part of the copy, which led to the connection to the configuration

There is also the opinion that this error provides the use of a dynamic update mechanism. There are doubts here, because on the one hand, the dynamic update never affects the structure of the database, and the Rib mechanisms are still working precisely with the database structure, and not with its own part, nevertheless, the RIB uses a digital signature mechanism for the configuration version (in I will be called it to reduce Hashe), and when changing the applied part, the hash is naturally obliged to recalculate. I will not deny it nor say, because If I came across this situation, I did not find this evidence.

For correction I use 2 techniques, depending on the situation.

First technique

The first (the most common) is repeatedly mentioned in the affiliate conference, and on other Internet resources associated with 1C. It is used in most cases when despite the message about the configurations, when compared manually, it is issued that they are identical.

Sequencing:

1. unload the CF file from the Central Bank;
2. we asslaunt the UB from Rib (the method of installing chain, ready-made processing can be found in the appendix or in other publications);
3. replace conf. UB on the CF file unloaded in the first step, to do this, use the "Download configuration from the file" menu (and not comparing-association !!!);
4. relative signs of Rib for UB.

In most cases, these actions are more than enough that restore the exchange, but not always ...

Second technique

It is used if the first technique did not work, and it is not possible to unload the node again.

Prehistory: The client had a cascade rib and the error occurred in the first level of the stage (the second level all this time worked flawlessly). The configuration development was carried out in conjunction with the IT client service and from the moment the error occurs, the CB configuration managed to change several times. An option with a rollback of changes was not considered even in principle, because Loss of data parts and stopping the work of several units were completely unacceptable. The first version of the correction of the error of any tangible results did not give. In this connection, what had to look for other solutions.

A thought has come to try to replace hashi configuration files directly in the XML exchange files. Description of the sharing file structure from the book "Professional development in System 1C: Enterprise 8" gave a weak understanding of the formation of digital configuration signatures and changes in them, but determined the search direction: Digest1 and Digest2 values. Everything else found out a purely empirical way (I mean by the method of samples and errors), but the regularity is to establish the same.

Test experiments were successful. On the working bases, too, everything went well.

So, the sequence of actions:

1. perform actions 1 - 4 of the first technique;
2. unload from UB file sharing, but do not load it in the Central Bank;
3. unload from the Central Bank the exchange file, but do not load it in the UB;
4. in the exchange file from the Central Bank, we replace a block containing information about configuration changes and hashi (Digest1 and Digest2), on the cache block from the UB file (see example below)
5. we produce the file download from the 4th point in the UB;
6. be sure to overwrite the exchange file from the UB (2nd item)! This file should not be downloaded when exchanging in the Central Bank!
7. for verification, we make several consecutive exchanges.

If the exchange is used to compress data, then either turn off the compression, or first unpack the file, change, then we are reversed back and send.

File sharing unit from the Central Bank

106.0 ... Here are the blocks for describing configuration changes ... 1CF680807E97A5DC0D1ED7F901B07392. 038211651CF680807E97A5DC0D1ED7F9.

you need to replace the exchange file from the UB (note the Digest1 from the file from the UB is always equal to "0000000000000000000000000000" !!!)

106.0 00000000000000000000000000000000 11651CF680807E97A5DC0D1ED7F901B0.

The listed actions must be carried out with marginal caution, the incorrect sequence is fraught with the complete inoperability of Rib. Therefore, before these actions, the creation of backup copies is required!

For the rest, I can only wish good luck!

Dynamic update errors (or other platform glitches) may be causes of distributed information database exchange errors:

• "Data is accepted from the node for which configuration changes are registered"
  

• "The configuration of the node distributed IB does not match the expected"
  

How to recover exchange?

But let's start not with the restoration, but with the ability to spend aboutbent "manually", which is important for the day, because, as always, everything should work "yesterday" :) It is possible to do it with the help of wonderful treatments that I do notnu where downloaded (authors, respond - leave links to your resource, and with mine, if necessary - delete). Processing makes it possible to unload only registered data changes in the database (according to the specified exchange plan for a specific node!) In XML without unloading configuration changes and if the configuration objects are not strongly modified, that is, very large chances of downloading these data. These processing can be downloaded by reference at the end of the article.

As for recovery. There are simpler methods that include not all items below the list below, but they do not always help, as it was in one of my cases. Therefore, I bring the way that helped me, he bypasses the possible problems more comprehensively. Further by steps.

Making the specified steps is preferably when there are no working users in the database. If it is impossible, you will come to "finish" the method for yourself, and therefore you need to first understand its logic.

1. Make backup copies everywhere.

2. For client-servers: Disconnect the databases through the "Server Administration" and immediately connect with the locking setting of the regulatory tasks (the server cache is reset). After that, do not forget to transfer the registration log in the new directory.

3. On all used to restore computers, delete the database in the 1C starter database list and create a Pona (Clear user cache)

4. In the configurator (in the central database), add a new constant to keep the changes of the confes.

5. Clear all exchange catalogs.

6. Make unloading to all branches (so far only unloading).

7. Try to download (just download) the data obtained to all branches. Naturally adopt a change of confes.

If everywhere is fine, go further, if everything is bad - we think, it may help unload .CF from the central base and its download to the branch (not comparison-association). In the subordinate node, it is necessary to untie the base from Rib (will help in this processing - download the link below). An article on this topic is on infoStart.ru.

8. We cancel the registration of changes for branches in the Central Bank (after all, all changes we have already received everywhere). It is important to do at this stage that the accumulated changes from different branches fall into other branches. (download processing for binding binding below).

9. We make the download in the Central Bank and if everything is fine, then we make downloading-unloading with each branch several times to secure the result.

10. Everything.

You can enable the execution of regulatory tasks from client-server databases.

To prevent problems that is called this error, it is recommended not to do a dynamic update (at least several times in a row - before downloading changes to branches), and it is also desirable to put the "Unscluded data only when successfully downloaded" in the exchange settings.