Enterprise accounting 1c 8.3 how to create a rib. Distributed information base: Basics. Basic operating principles of RIB
October 25th, 2016
There is no big difference between setting up and supporting RIB for 2 nodes and for 10, but when the number of remote points exceeds a hundred, completely different issues have to be solved
Initial data:
Configuration: Retail 2.2
Platform 1C: 8.3.7.1970
Project duration: one year.
Architecture:
First, we decided on the RIB scheme. It was decided to focus on the “star” scheme for as long as possible; when technological limitations are reached - a snowflake.
Limitations:
- 2 GB RAM
- 1 physical processor
Of all the above, the main annoying thing is the limitation on the maximum database size.
But this just means that you need to carefully organize a procedure for cleaning it from outdated data on site.
A separate physical server is allocated for the 1C and MS SQL server. It will bear the main burden of exchanges and long-term operations.
The end client computers are not replaced, because they will work with the thin client and the load on them will be minimal.
.
Basic settings
Since the time of UT 10.3, during which I had my first project of implementing RIB for 60 knots, of course, “a lot of water has passed under the bridge.”
1C did not stand still. Retail 2.2 now takes into account the need for selective data upload.
Only information that is relevant to it will be uploaded to the store database:
- All reference books (except specialized ones)
- Documents for this store
Another question is that one way or another, adding a node to the database means adding another entry to the registration table for each common element when it is written.
1) It is necessary to divide into separate synchronization scenarios for uploading and downloading
The point is that unloading takes a long time and involves blocking, while loading is quite hassle-free. At the same time, it often happens that we need to quickly receive data from retail outlets, while giving it away only a few times a day.
2) Identify problem stores and remove them from the general synchronization scenario. There may be large unloadings on them - this will slow down the entire exchange, including other nodes. Once the problems are resolved they are added back.
3) Create several scripts for sending and receiving data. But the main thing here is to catch the right balance of their quantity.
(since version 8.1).
Consequently, parallelism in unloading RIB is limited. In practice, it turns out to run 2-3 scripts in parallel.
What had to be improved
The most important problem in the standard logic of 1C RIB is updates
Another problem of exchange is information registers. Uploading each record of the information register into XML creates a separate XML node with service elements, etc. In addition, the “SelectChanges()” function for an information register in which there are 100 records will receive a resulting table of 100 rows, at the same time, if this A directory with 100 rows will have only one entry selected in its tabular section. And this is the time of exclusive blocking. So if there are a lot of records in the PC that are regularly registered for exchange to other stores, then it is of course more correct to present this in the form of a directory with a tabular part, which, in extreme cases, when recording, can form rows of the same register. Anyway, .
Another important detail - For what? There are already close to 3 million discount cards. An external online system is used to work with them. If you continue to transfer discount cards to all stores, this will increase exchanges several times, in addition, it may lead to the base exceeding the volume of 10 GB.
Some of the mechanisms are implemented online by contacting the central database: balances in other stores, returning a receipt from another store, checking the validity of a gift certificate.
Replication
Creating an initial RIB node in a regular manner would make replication impossible in principle.
Therefore, a new node is created as follows:
2) This database exchanges all general data in the RIB but does not receive specialized (documents)
5) The base for the store is ready.
A ready-made software package is deployed onto the server, so it does not take much time. Then the newly created database is uploaded to the server and it is ready to be sent to the store.
Benefits of a thin client
Two significant advantages of Retail 2.2 (Thin Client) that “warmed the soul”:
Support and updates
1) Update manually from stores (not very correct, changes may not be received, there will be calls and problems) - this was the case before
3) Write a *.cmd or 1C script for updating or take a ready-made one. As practice shows, such a solution is always half-hearted (unstable), and it will be possible to build little functionality into it.
What were our tasks:
2) When updating, interactive interaction with the user is possible (messages, confirmation, progress bar).
Main functions:
4) Checking the status of agents
5) Update reports
6) backup
For example, this is what the error message looks like after an update:
Thus, the project had a good chance of being completed successfully. At least halfway through the flight the flight is normal.
If we come to any other solutions that may seem interesting, I will write separately
P.S. and most importantly: Proper planning of further support is one of the key factors for the further success of such projects. :)
October 25th, 2016
There is no big difference between setting up and supporting RIB for 2 nodes and for 10, but when the number of remote points exceeds a hundred, completely different issues have to be solved.
So, the initial data:
Configuration: Retail 2.2
Platform 1C: 8.3.7.1970
Estimated number of nodes at the end of the project: 200
Equipment resources in the center: without significant restrictions
Equipment at the point: a discussed issue.
Project duration: one year.
Architecture:
First, we decided on the RIB scheme. It was decided to focus on the “star” scheme, before
At retail outlets, a client-server version of work is used, with a dedicated server running Windows OS.
Server 1C will be used in the version "Server 1C MINI" https://1c.ru/news/info.jsp?id=17577
DBMS server - MS SQL Express 2008 R2.
SQL Express 2008 R2 is the current latest version of this SQL Server line.
Limitations:
2 GB RAM
- 1 physical processor
- 10 GB maximum database size
Of all the above, the most annoying thing, of course, is the limitation on the maximum database size. But in fact, this just means that it will be necessary to carefully organize the procedure for cleaning it from outdated data on site.
A separate server is allocated for 1C and MS SQL server. It will bear the main burden of exchanges and transactions.
The end client computers are not replaced, because they will work with a thin client and the load on the bottom will be minimal.
The server in the store is simply a powerful PC. But a prerequisite is the presence of an SSD disk - on which the MS SQL databases are located.
The server will also provide the ability to carry out routine operations at night and access to the store’s database without interruption from work.
Basic settings
Since the time of UT 10.3, during which I had my first project of implementing RIB for 60 knots, of course, “a lot of water has flown under the bridge.” 1C did not stand still. Retail 2.2 now takes into account the need for selective data upload.
Only information that is relevant to the store will be uploaded to the store database:
- All directories (except some)
- Documents for this store
Data registration occurs according to registration rules, everything that can be cached. There are no significant slowdowns during registration.
Another question is that one way or another, adding a node to the database means adding another record for each common element for all databases.
There is nothing specific in setting up the upload itself. There are some nuances when setting up synchronization scenarios:
1) It is necessary to separate uploading and loading into separate synchronization scenarios
The point is that unloading takes a long time and involves blocking, but loading is quite trouble-free. At the same time, it often happens that we need to quickly receive data from retail outlets, while giving it away only a few times a day.
2) Identify problem stores and remove them from the general synchronization scenario. There may be large unloads on them - this will slow down the entire exchange, including other nodes
3) Create some send and receive scripts to send and receive data. But the main thing here is balance.
Some things in 1C do not change. The same "SelectChanges" method can only be executed sequentially(since version 8.1).
Consequently, parallelism in unloading RIB is limited. In practice, you end up uploading 2-3 scripts at a time.
As for the receiving scenario, much greater parallelism is possible here, if necessary, of course.
What had to be improved
Of course it’s sad and sad, but I had to thoroughly interfere with the BSP. The most important problem in the standard 1C logic is updates. After the update, a window similar to this appears:
This all happens in monopoly mode. Among other things, the system will still try to make an exchange after updating in exclusive mode. It’s not hard to guess where this all leads.
During this entire period of time, the store cannot operate, there are customers at the checkout, and the company is losing money.
Another problem of exchange is information registers. Uploading each information register entry into XML creates a separate XML node with service elements and everything that follows. In addition, the “select changes” function for an information register in which there are 100 records, the resulting table will contain 100 rows, at the same time, if this is a directory with 100 rows, only one record will be selected in the table section. So if there are a lot of records in the PC that are regularly registered for exchange to other stores, then it is of course more correct to present this in the form of a directory with a tabular part, which, in extreme cases, when recording, can generate records of the same register. Anyway, information registers in exchanges are evil.
Another important detail - Discount cards are completely excluded from the exchange, and only employees of a specific store are excluded from the exchange. For what? There are already close to 3 million discount cards. An external online system is used to work with them. If you continue to transfer discount cards to all stores, this will increase exchanges several times, in addition, it may lead to the base exceeding the volume of 3GB.
Some of the mechanisms are implemented online by contacting the central database: balances in other stores, returning a receipt from another store, checking the validity of a gift certificate.
Replication
Of course, replication is being carried out at an accelerated pace.
Creating the initial RIB node in a standard way would, of course, make replication impossible.
Therefore, a new node is created as follows:
1) There is a separate database with a fake store
2) This database exchanges all general data in the RIB but does not receive specialized
3) When we want to create a new database, we simply copy this one
4) Then we set the settings - store, prefix, etc.
5) The base for the store is ready.
A ready-made software package is deployed onto the server, so it does not take much time. Then the newly created database of stores is uploaded to the server and it is ready to be sent to the store.
Benefits of a thin client
two significant advantages that “warmed the soul.”
1) There is no need to change the entire computer park at retail outlets. 90% of operations are performed on the server, and the server is brought there with a “relatively powerful computer”
2) Equipment has the ability to refuse to work, this especially often happens with newly installed or already worn-out equipment.
In this case, the actions are now extremely simple - the store switches to working in the central database.
This process takes no more than 5-10 minutes, so trading is not interrupted even if there are significant problems with the equipment.
Support and updates
Finally we reached the most interesting point - how to maintain and update all this?
For us, updates have also been a dilemma for a long time:
1) Update manually from stores (not very correct, changes may not be received, there will be calls and problems)
2) Update using technical support (there are not so many resources)
3) Write *.cmd for updating or take a ready-made one. As practice shows, such a solution is always half-hearted (unstable), and there is little functionality in it.
What were our tasks:
1) The update must take place in several modes and be managed centrally
2) When updating, interactive interaction with the user is possible.
3) Reports on update status and errors must be received
4) There must be a backup
5) The update system should be able to update itself without problems.
6) The system should be expandable without any problems.
Of course, the problems went far beyond the list of those solvable by simple methods. Because we can’t do without automation with so many endpoints, and we haven’t found anything more or less ready-made with similar functionality
I had to start developing software, which eventually acquired the name MU (MagicUpdater).
Main functions:
1) Dynamic database update (command or scheduled)
2) Static database update (command or scheduled)
3) automatic agents on end computers when they are modified
4) Checking the status of agents
5) Update reports
6) backup
7) Administrative actions with 1C server and MS SQL
8) Closing all 1C client applications on network computers
9) Static update with acceptance at the main checkout
10) Displaying descriptions of modifications after updating
11) Setting up the order of actions
12) Perform all these actions on a schedule
Approximate interaction schemes:
Where MU Agent is a service that is installed and configured in the store. Actually, she receives a command from the center to carry out certain tasks.
MU Server - The server that receives all requests to the system.
The MU monitor - what ordinary technical support employees see - is used to view logs and set tasks for updating, or others.
It turned out quite well, in my opinion. Now updates take place almost automatically.
This is, for example, what the error message looks like after the update; everything is still waiting in the center.
And this is how we send commands to client computers
The applications are certainly not 1C, but with a fairly decent set of interface capabilities. For example, this is what selection by date looks like:
Now they are ready for further replication. Proper planning of further support is one of the key factors for the further success of such projects.
Creating and configuring a distributed database (RDB) in 1C 8.3 Accounting (and other configurations) is necessary in cases where it is not possible for several users to work while simultaneously connecting to one database. Nowadays this is quite a rare occurrence, since the standard remote desktop works fine and there are other programs that provide a remote connection to the central computer where the database is located.
But nevertheless, there are situations when there is simply no Internet. And the data should ultimately end up in one information base. This is why a distributed database is created.
Usually the main base is called central, and the rest are called peripheral. The bottom line is that either manually or automatically (depending on the settings) the databases are combined into one. To ensure that numbers of newly entered documents and directory codes are not duplicated, a prefix is assigned to each database.
In this instruction, we will use an example to create a central and peripheral database and check the exchange between them. This manual is suitable for both 1C 8.3 Accounting and 1C Trade Management (UT) and other configurations.
Setting up the main (central) distributed RIB database
Let’s go to the 1C “Administration” menu, then click on the “Data synchronization settings” link. In the window that opens, you need to check the “Data synchronization” checkbox. The “Data Synchronization” link will become active. Right here we will set a prefix for the main information base - for example, “CB”:
Click on the “Data synchronization” link and a window will open with a “Set up data synchronization” button. When you click on this button, a drop-down list will open where you need to select the “Full” mode. If synchronization is required for only one organization, you need to select “By organization...”.
In the next window, the program will prompt us to make a backup copy. I strongly recommend doing this, as the following setup steps may be irreversible.
After creating a backup, click the “Next” button. At the next step, we need to decide how synchronization will occur:
- through a local directory or a directory on the local network;
- over the Internet via FTP.
For simplicity and clarity of the example, we will select a local directory. I specified the following path: “D:\1C Databases\Synchronization”. It would be a good idea to check entries in this directory; there is a special button for this:
Get 267 video lessons on 1C for free:
We skip the next steps with setting up synchronization via FTP and email. Let's look at the settings for the names of the main and peripheral databases. Here we will set the prefix for the peripheral database:
Don't forget that the prefixes for each database must be unique. Otherwise, you will receive the error “The prefix value of the first infobase is not unique.”
Click “Next”, check the entered information and click “Next” again, then “Finish”. In the “Full name of the file base” field, indicate the file 1Cv8.1CD in the directory that was created for synchronization. We create the initial image of the distributed 1C database:
After creating the initial image of the RIB in 1C, you can set a synchronization schedule or synchronize manually:
After synchronization, you can connect to the new database and make sure that information from the central database has been uploaded there:
Just immediately create at least one user with Administrator rights in the new peripheral database.
Setting up synchronization in the peripheral database
In the 1C peripheral database, configuration is much simpler. Just check the “Data synchronization” checkbox and follow the link of the same name. And we almost immediately find ourselves in a window with the “Synchronize” button. Let's try to create a test item in the peripheral database and upload it to the main one using RIB:
Task: it is necessary to configure the information base so that three users who are not on the local network, but connected to the Internet, can work in one working database.
Let's accomplish this task by setting up a Distributed Information Base. Information base configuration – “Enterprise Accounting 2.0”.
Setting up an FTP resource.
Let's set up FTP using HCube as an example: Go to the website hcube.ru. Hosting tab, FTP Hosting (http://www.hcube.ru/hosting/ftp/). We choose the minimum FTP tariff plan -10, this will be enough for exchange between nodes of the distributed information base. You can order a trial period of 15 days, click “Try”. Next we need to register:
Specify the username and password to access your personal account. After the application has been accepted, we are waiting for a letter to the specified email with FTP access details. Information about the configuration of your hosting service: ************************************************** *********************
Hosting login: user725
Hosting password: ffUXP3CDU
Hosting IP address: 85.10.207.234
****************************************************************
Control panel for FTP hosting https://cp.hcube.ru/manager/ispmgr 
We are waiting for the state to become “Active”.
Setting up an exchange plan.
It is necessary to determine the central node of the database. Let's choose a workstation located in the office as the central node. The other two will communicate with the central node. Let's set up the central node. To do this, you must log in to the information security system as a user with full rights. In the main menu of the program, select the item "Operations / Exchange Plans...". In the exchange plans of the standard configuration “Enterprise Accounting 8”, 7 standard exchange plans have already been created: 
Opening the plan "Full". It contains one predefined empty entry. This entry describes the current node. Predetermined, i.e. An entry added at the configuration level cannot be deleted, but it can be corrected. Click edit: field "Name" can be arbitrary, for example "Central Node". "Code" can also be arbitrary, for example "01", click "OK". The current node has been described, now it is necessary to describe the slave nodes. Adding new elements with the name "Node 1" and code "02" And "Node 2" with code "03". We get three nodes: 
There can be many slave nodes in the RIB and the exchange will be carried out between one central node and each of the slave nodes. Now let's physically create a slave node (a new database). To do this, you need to stand on the knot line "Node 1" and click on the icon “Create initial image...” or select this action from the menu: 
The system will prompt you to select the type of information base (IS). Must select "On this computer...". Then specify the directory in which the new information security will be created. After this, a new database will be created in the specified directory and all data from the main database will be transferred to this database. It’s worth noting right away that the new information security is not an exact copy of the original one. It has its own settings (its own list of users, etc.), only data and modified exchange plans are transferred, i.e. in the new information security there will be only two nodes "Central Node" And "Node 1". If the source database is large and there are users working in it, there may be collisions when creating the initial image, so it is recommended that the operation of creating a new image be carried out in monopoly mode. If several slave nodes were described in the central node, the operation to create an initial information security image must be carried out for each node, i.e. as many new information security systems will be created as the number of nodes described in the original database. We'll do the same for "Node 2". At the time of creating the initial image, a table will be created in the main database for synchronizing objects of the main database with this node. In general, such tables are created according to the number of slave nodes. When creating the initial image of a node, the synchronization flag with the node is set. Now the databases of slave nodes need to be copied to workstations "Node 1" And "Node 2". After this, the three computers will have identical (in terms of data) information bases.
Distributed infobase exchange settings.
In this problem we have a general case when all three databases are working, i.e. documents are entered and modified in three databases. Let's go to the menu “Service / Distributed information base (RIB) / Configure RIB nodes”. Let's set up an exchange between Central hub And Node 1. On the “Distributed infobases” tab, add a new element, let’s call it "Office - Node 1"(where "Office" is our Central Hub). Select from the props "Knot" – "Node 1". In the field "Exchange Type" choose "Exchange through FTP resource". We fill in the details that were sent to us by email: "Address", "User", "Password". Tabs "Interactive Exchange" And "Automatic exchange" We don’t fill it out yet, we’ll do it after the basic exchange settings in all nodes. 
Next, by analogy, we will create a new element for setting up the exchange between the Central Node and Node 2. 
Let's go to the previously created initial image (information base) Node 1 and create settings "Node 1 - Office".
Let's do the same in Node 2. 
On the tab "Interactive Exchange" we can determine whether we need to both upload and download data, or just one thing. 
On the tab "Automatic exchange" you can add a new element to configure automatic exchange. Here we can set a schedule for a specific exchange, for example for "Office - Node 1", and/or event-based exchange. 
When selecting a user in the event exchange settings, you must also specify this user in "Program settings" on the tab "Data exchange".
The exchange in our example will be carried out only if the database is logged in as specified in the settings "Exchange by Event" user. You also need to indicate "Node prefix for distributed infobase" for correct numbering of documents. Using the prefix, we can see which node created the document, and also avoid duplicating document numbers. For convenient work in the Distributed Information Base, it is necessary to carefully consider the cycle of exchange of nodes with each other, the exchange schedule and/or exchange by events for a specific task.
Instructions for creating and configuring distributed databases using the URDB (URIB) component
The URDB (Distributed Database Management) component is used to exchange information between two identical 1C databases. If the configurations are different, then you can also use it, this is written in another. For the component to work, you must have the DistrDB.dll file in the BIN folder of the 1C: Enterprise program.
Let's look at the steps to create distributed databases. For example, we have a working base in the D:\base1 directory. It is required to make it central and create a peripheral base.
1. Create a directory D:\base2 for the peripheral database.
2. In the directories D:\base1 and D:\base2, create the folders CP and PC (use Latin letters).
3. Launch the central database configurator (D:\base1) and select Menu - Administration - Distributed Information Security - Management.
4. Click the “Central Information Security” button, in the window that appears, enter the code and name of the database. It is better to use numbers or Latin letters for the code. Enter, for example, 001 and “Central base”, confirm by pressing the “OK” button.
5. Click the "New peripheral information security" button to create a peripheral database. We enter the parameters for it: 002 and “Peripheral base 1”.
6. Use the cursor to select the “Peripheral base 1” base and press the “Setup” button. auto exchange". In the settings, change the manual mode to automatic. Be careful, this is important.
7. Using the cursor, select the “Peripheral base 1” database and press the “Upload data” button, then the “OK” button. As a result of the upload, the file D:\base1\CP\020.zip will appear.
8. Launch 1C in configurator mode, add a new database “Peripheral database 1” in the 1C launch window, specify the previously created directory D:\base2 for it.
9. Select Menu - Administration - Distributed Information Security - Management. To the question asked “The information base was not found. Do you want to load data?" Click the "Yes" button and specify the file name "D:\base1\CP\020.zip", click the "OK" button. After the download is complete, the process of creating a peripheral database can be considered complete.
In and also in C there are ways to create a peripheral database by restoring a copy of the central database from a backup or attaching files from a copy of the central database in SQL format and executing the script. This will be useful for large volumes of data, when uploads and downloads take hours or are completely unrealistic.
Instructions for exchanging between distributed databases using the URDB (URIB) component
Let's consider a simplified example; we will perform the exchange manually by launching the configurator. You can use the batch mode of the configurator; you can use mail, ftp, and automatic file copying to deliver exchange packages.
To perform the exchange, you must select Menu - Administration - Distributed Information Security - Auto Exchange. If the exchange is automatic (see point 6 of the previous instructions), then everything will work out.
1. So, we change or create some objects that migrate to the peripheral database. Object migration rules are set on the "Migration" tab in the object properties (see the object tree in the configurator).
2. Launch the central database configurator, select Menu - Administration - Distributed Information Security - Auto Exchange, click the "Run" button.
3. Move the resulting file D:\base1\CP\020.zip to the folder D:\base2\CP\
4. We change some objects in the peripheral database. Preferably not those that were changed before in the central database, because the central database has priority for object changes during exchange.
5. Launch the peripheral database configurator, select Menu - Administration - Distributed Information Security - Auto Exchange, click the "Run" button.
6. As a result of the auto-exchange, we should have changes coming from the central database. We should also have a file to transfer to the central database D:\base2\PC\021.zip
7. Copy the file D:\base2\PC\021.zip to the folder D:\base1\PC
8. Repeat point 2. As a result, changes received from the peripheral database will appear in the central database.
So, the general principle of exchange: alternate execution of auto-exchange with simultaneous movement of files (exchange packages) from the PC folder of one database to the PC folder of another database and from the CP folder of one database to the CP folder of another database.
Configuration changes are made only in the central database. When changing the configuration, it is necessary to carry out the exchange in peripheral databases in exclusive mode. To successfully process packets from peripheral databases in the central database, the configuration must be loaded into the peripheral databases. If you get confused, it’s okay, the package rejected by the central database will be downloaded again.
This material contains detailed instructions for setting up the RIB exchange for 1C:Enterprise 8 and the problems that the author encountered.
1. Creating nodes
We create new nodes (master and slave): in the user mode "Operations / Exchange Plans / Full"
Let's choose the exchange plan "Full"
We create two records:
- let’s call the first record “CB” (main node), indicate the code “CB”,
- let’s call the second entry “Subordinate node”, indicate the code “PU”.
Icon with a green circle - "CB" (main node)
For the slave node, click on the “Create initial image” icon. (Requires exclusive access)
Create a starting image
Next, in the window that opens, fill in the parameters of the new database. When finished, click the “Finish” button.
Creating an initial information security image
The creation of the initial image of the slave node of the distributed infobase will begin, and upon completion the message “Creation of the initial image has been successfully completed” will appear. Click the "OK" button.
We add the base of the slave node to the list of bases and launch it.
In this subordinate database we open the full exchange plan - the “CB” icon is red, this means that this node is the main node for the information base in which we are located.
2. Setting up prefixes
For each database, in the accounting parameters settings (in the UPP "Service / Accounting Parameters") on the "Data Exchange" tab, we set prefixes. This is done so that there are no conflicts in the numbers and codes of documents and directories created in two databases.
For automatic exchange, check the box "Use automatic exchange mechanism..."
Tab "Data exchange"
3. Add a setting for data exchange between nodes
Open: "Service\Distributed Information Base (RIB)\Configure RIB nodes"
Click "Add" and the "Data exchange settings" window will open.
Setting up data exchange
Click on the "Exchange according to current settings" icon
Execute the exchange according to the current setting
Now about the pitfalls
1. Data exchange can be carried out automatically and can be initiated in the following cases:
* When starting the program. The exchange will be performed when the program starts,
* When you finish working with the program. The exchange will be performed before the user finishes working with the program,
* When the catalog appears. The exchange will be performed only if the directory specified by the user was invisible, but has now become visible. The setting can be used to perform automatic exchange when connected to a local network or flash card. The program will periodically check the visibility of the directory specified in the settings and note its current state,
* When the file appears. It is recommended to use data mode when you need to exchange if an incoming data exchange file appears. In this case, it is enough to specify the full path to the incoming data exchange file. The program periodically analyzes the presence of the file, and as soon as it appears, the exchange will be performed, and after the exchange, this file will be forcibly DELETED (this is done so that the exchange procedure is not carried out constantly),
* Periodic data exchange. The exchange will be carried out according to the settings for periodic data exchange. If the infobase operates in file server mode, then periodic exchange is performed only for the user who is specified in the accounting policy settings as “User for routine tasks in file mode.” In the Client-server version, the exchange is performed on the 1C:Enterprise server.
I have a Client-Server option - for routine auto-exchange to work I had to overload the server
2. Windows encoding.
The exchange was interrupted by an error because the file was not compressed. This is due to a Cyrillic error in the command line during compression.
It can be treated by correcting the encodings in the registry.
For example, for Windows Server 2008 -
Code
REGEDIT4
"1250"="c_1251.nls"
"1251"="c_1251.nls"
"1252"="c_1251.nls"
"1253"="c_1251.nls"
"1254"="c_1251.nls"
"1255"="c_1251.nls"
3. When creating a copy of the database (for example, for modification) in the client-server version, it is NECESSARY that the ROUTINE TASKS OF THE COPY OF THE DATABASE be OFF. Blocking routine tasks for copy ON
If they are not blocked, then the copy will make exchanges on the same schedule as the main database. This means that some messages to remote nodes will be generated from the working database, and some from a copy, which will lead to desynchronization of configurations.
