1s 8 ribs and added objects. Alexey Alekseev welcome to my cozy blog

This is my first article, constructive criticism is welcome.

The target audience is those who are encountering RBD for the first time.

RDB tasks

The first thing you need to start with is answering the question “Why do we need a RDB?” There are many possible answers, in particular:

We have branches running in disconnected databases. Now we want the information between them to be synchronized;
We have branches, but the load on the database is too high (this means transaction blocking, not the volume of the database) and online relevance (not to be confused with relevance in a few minutes, online is when after each transaction the data is transferred to the second node) there is no data for branches required;
We have branches where only data entry occurs (for example, retail stores), so we can significantly reduce the load on the central database;
For security reasons, we want the branches to have no access, even theoretically (with an admin password), to important data, such as the company’s balance sheet.

In one case, questions 2 and 4 were relevant to me, in another, 2 and 3. The first point is too extensive and will not be considered within the scope of this article.

It is also better to immediately consider the problem of transporting exchange files, because in some cases it can impose significant restrictions on the implementation of data exchange. First, you need to determine in which branches exactly the RDB nodes will appear (usually these are regional branches). Next, we consider where else we want to install RDB nodes, and whether they need online relevance. For example, for retail stores it is not always possible to install even a modem, and installing a wireless connection will be too expensive. Here you need to make a decision - perhaps this store can operate offline and periodically exchange with the center (once a day/once a week) using a physical medium, such as a flash drive.

In some cases, exchange via physical media is not possible, for example, this is a very remote branch where there are significant problems with setting up high-speed communication. Here it is worth roughly calculating the amount of information exchanged. Often, if it is relevant once an hour or several times a day, a 32k modem is enough. However, it is worth remembering that along with data updates you will sometimes have to send updates to the configuration itself or external files (printed forms, photographs of goods), so from time to time a situation will arise when the exchange file increases significantly due to such updates.

Topology

In total, we received the following questions that need to be answered:

In which departments are we guaranteed to install RDB nodes and is it possible to install a high-speed channel there;
In which departments is the installation of a RBD unit not required?
Which departments can work with relevance in several hours;
Which departments can work offline (data exchange less than 3-4 times a day).

Having answered these questions, we get an approximate diagram of our RDB. For large companies, it usually turns out something like this:

Fig 1. Typical diagram of the RDB of a large company

If everything is relatively clear with the “Branch” nodes - these are large centers that require automation, then the “Store” nodes mean a node with a serious load on the database when entering data, which should be separated to reduce the load. For example, a store with 50 cash registers and a daily turnover of more than 10,000 units.

Stores - enter data on your own turnover and cash flow. The analytics are superficial, only for your own store.
Branches - data entry of non-automated points, accounting, salaries and personnel, production, etc. Analytics within your own branch.
Center - data entry of non-automated branches. Analytics of the enterprise as a whole.

It is important to understand for what purposes the database will be used in each node. From the goals, the tasks necessary for implementation are built, for example:

Branches see the history of mutual settlements with each other’s counterparties;
Stores see leftover goods in the entire (or part of) the enterprise;
Analytics of income/expenses, budget execution, etc. are visible only within the hierarchy of your own department;
Accounting, payroll and personnel are visible only within the hierarchy of your own department;
The nomenclature, all its properties and characteristics are visible in all nodes of the RDB;
With respect to the departmental hierarchy, all data flows upward, but is filtered downward;
The center contains absolutely all information about the company.

By asking yourself such questions, you can answer the most difficult question - what information, where and how should flow between RDB nodes? Why the most difficult? Knowing which sets of data circulate between nodes, you can clearly understand how to “cut” the current database so that the data remains logically consistent. For example, data on goods balances cannot be separated from data on current reserves.

Now, depending on the information flows, let’s redraw the RDB diagram:

What do we see in Figure 2? According to the hierarchy of the company's divisions, a topology of information flow between the database nodes was built. The “Center 2” node has also been added, why? When implementing the Star topology, the load on the center is always higher than the load on the peripheral nodes, and often the load generated by the node itself is already high. Examples of using the “Center 1” and “Center 2” nodes:

“Center 1” serves only to consolidate data from other RDB nodes. Only the administrator has access to it. "Center 2" serves for the work of the head office;
“Center 1” serves for the work of the head office. However, heavy analytical and testing operations that create a huge load on the database are performed in the “Center 2” node; for example, restoring the sequence, rescheduling closed periods, generating summary reports for the entire enterprise over a long period of time, generating analytics that lead to changes in data;
“Center 1” serves for the work of the head office. “Center 2” is a backup in case of unforeseen situations for the quick restoration of the entire RDB.

Implementation of exchange

There are 2 options for RDB operation:

Automatic - occurs without user intervention. Control over emergency situations is assigned either to the database administrator or to an advanced user;
Manual - exchange occurs only at the request of the user.

In my experience, I always led all implementations to the automatic version. If there were problems with the transport of exchange files (the presence of a network in the node is not constant), then the maximum that the user could do was click the “Exchange Now” button. Situations where, in addition to updating data, there is a configuration update, it is advisable to also do it fully automatically (for example, using third-party software).

Generating update packages

Since there is an unambiguous decision about which RDB nodes are assigned which functions, it is possible to generate only the data package that this node needs. On the one hand, it is necessary to specify what types of objects will be synchronized between nodes. For example, accounting registers for the “Store 1” node should not be synchronized at all, because Data is entered only at the branch node level. On the other hand, those types of data that are subject to exchange must be filtered with reference to the department. For example, data on the receipt of money from the “Store 1 branch 2” node can only be located in the “Branch 2”, “Center 1” and “Center 2” nodes.

However, there is also the opposite problem: if you filter the exchange data too much, the data packet will lose its logical integrity. For example, the balances of goods are taken into account in the context of warehouses, and reserves are taken into account in the context of the company as a whole, then if you filter the balances of goods by warehouses and do not filter reserves, the data will be incorrect.

You should also decide at what stage in its life the object should be exchanged. For example, only posted invoices can be exchanged, but not simply saved ones. Either Store invoices are never unloaded from the Center node, even after they are adjusted, but the opposite effect must be taken into account - the data may be out of sync, or some changes may be overwritten.

It is important to understand that when exchanging between nodes, one of them has priority. Consider the situation:

A document was created in the “Shop 1” node;
During the exchange, he ended up in the “Branch 1” node;
The document is corrected simultaneously in both nodes.

Which document will be considered true? In 1C 8.x, when using the “Exchange Plans” mechanism, the default priority is the main node, i.e. in this case, the changes made in the “Store 1” node will be lost and replaced with data from the “Branch 1” node.

There is another, more complex situation when two connected objects are adjusted simultaneously. For example, the invoice and the PQR for it are adjusted in different nodes; there is a possibility of loss of integrity if prices, payment amounts, counterparties, etc. are changed.

It is also important to control the deletion of objects, otherwise this may lead to the fact that, for example, an invoice will no longer exist, but accounting movements will remain.

Exchange mechanisms in 1C 8.x

There are two approaches for implementation:

“Exchange Plans” mechanism;
Own implementation of object registration.

Let's consider both options.

The mechanism of exchange plans allows, without any configuration, in a few minutes, to create a database with complete data exchange. If you set the “Distributed infobase” flag, then when creating an update package, configuration updates will also be downloaded. In just a few minutes, you can set up rules for allowing/prohibiting the exchange of various types of data by opening the composition of the exchange plan. If you set the “Auto-registration” flag to the “Deny” position, then this type of object will never be exchanged without additional effort.

Why do you need registration, why not upload everything at once? In any case, a file containing only changes to the state of the database will be smaller than a complete snapshot of the database itself. Therefore, the option of complete unloading will not be considered.

How to set up data filtering by department affiliation? Here you will already have to program. In my implementation, a subscription to the “When writing” event was installed on the recording of any object, where, using the “Data Exchange. Recipients” property, you can set the list of recipients of this object. Those. When unloading using standard means for a node that is not in the list, the object will not be unloaded. There is another solution - you can choose whether to unload an object directly when unloading the object, in the procedures “When Sending Data to a Subordinate” and “When Sending Data to a Master” of the exchange plan module.

Both options have a right to exist. However, I chose the first option as the best option, because the calculation of the preloadability attribute occurs immediately when the object is written, which increases the duration of the object recording by 3-5% (can be optimized, in some cases it can be reduced to 0.01%), i.e. on average 0.1-0.3 seconds, and in the case of calculating the unloadability of an object directly when sending data, which already creates a significant load on the database, this time will be up to several minutes.

To fully understand the operation of the “Exchange Plans” mechanism, I recommend reading Chapter 15 of the book “Professional development in the 1C:Enterprise 8 system”, Gabets A.P., Goncharov D.I.

Any own implementation, in my opinion, will either repeat the “Exchange Plans” mechanism, or will unload the object immediately when changing, or will unload more than the “Exchange Plans” mechanism (for example, unload all changes for today). I do not consider this issue due to lack of implementation experience.

Transport

The task of transporting files from the master to the slave node is reduced to maximum fault tolerance. It is not uncommon for files to be encrypted or transmitted over a secure channel. To transfer files, it is advisable to use several different services, or prepare several different connection options. For example, the main transfer method is using an FTP server connected via a VPN tunnel; The backup one is an e-mail server with a TLS connection. Why do you need a backup channel with another service? As practice shows, using 2 different FTP servers is less reliable than an FTP server and E-Mail.

I recommend separating the update package creation service from the transport service, this will increase the fault tolerance of the entire data exchange complex. If the file transport service does not work, the service for creating update packages will continue to work normally and, under certain conditions, will restart the transport service and vice versa.

My RDB implementation

The implementation is completely autonomous, so maximum fault tolerance acted as a subtask. This resulted in 2 services - the update transport service and the data import/export service. Both services operate independently of each other.

After each successful data import-export cycle, the time of the last exchange with this node was saved. If the exchange did not take place for a very long time, then the transport service began to upload files to all communication channels available to it, with the expectation that the second node would still receive updates and upload its files. In case of exceptional situations, the system itself sends a message to the administrator with a detailed description of the error.

To reduce the amount of traffic, xml files were packaged in zip archives. The system supports two types of transport - FTP and E-mail.

There are two tables as settings for the data filter. One (the tabular part of exchange plans) stores conditions for general details (for each object the system tries to find this detail), the other contains settings for a specific metadata object. When recording any object, conditions are first searched for by general details (for example, Division), after which the system tries to determine whether there is a personal rule for this type of object using all its details. I do not recommend filtering the lists - there is a high possibility of making a mistake, for example, several lines will disappear from the tabular part of the invoice, and the remaining balance will move and vice versa.

It is important to understand under which system user the services will run, because You may not have enough rights to create files even in the 1C temporary folder. For debugging, I highly recommend writing each successfully completed operation to the registration log or to a txt file. In 1C 8.1, the execution of server code cannot be debugged.

For the convenience of debugging and setting up my implementation, I am attaching the “Registration of Changes” processing, the description of which is in the processing itself.

The general operating diagram of the data exchange complex is shown in Fig. 3.

Data filtering occurs in a subscription to the “BeforeRecording” event of each object. Don't forget that when creating the initial node image, the data also needs to be filtered. The procedure for creating an initial image is quite lengthy, so I recommend optimizing its code to the maximum (for example, caching filtering settings).

Afterword

The main task is to answer a list of questions:

Why do we need RDB?
What's not to like about working through an RDP client?
Where and why do we want to install RDB nodes?
How will the updates be transported?
What level of fault tolerance will be implemented?

Processing "Registration of Changes"

Processing allows you to force changes to objects to be registered. There are several options for logging changes:

If any metadata is checked and no objects are selected and the "Load by all values" flag is NOT set, then ONLY THE SELECTED TABLE IS REGISTERED;
If the "Upload for all values" flag is set, then the selected metadata will be unloaded for all objects in the cycle;
If the switch is set to the "Upload only selected objects" mode, then only selected objects will be unloaded (for example: setting a flag on metadata without selecting objects is equivalent to turning on the "Upload by all values" flag and the switch in the "Unload only selected objects" position;
If the switch is set to the "Unload selected and directly related objects" mode, then the selected objects and those objects whose existence depends on the existence of the selected object will be unloaded (for example: for directories - subordinate directories);
If the switch is set to the "Upload using all links" mode, then ALL objects that contain a link to the selected object will be unloaded.

Additional functionality available:

Re-registering registered objects is often required for debugging;
Removing registered ones is often required for debugging;
Print changes - print a complete list of objects that are marked as changed;
Printing the configuration tree is only for convenience of viewing the entire configuration.

Distributed Information Base (DIB) - used when it is necessary to have access to distributed data of a campaign or enterprise in order to use and exchange the information contained in them.

An example is the configuration of Trade Management 11 (11.0.6.9) - 1C 8.2 platform.

In order to create a Distribution Information Base, you need to perform the operations below.

The first thing we do is launch 1C:Enterprise, then go to the "Administration" tab and ultimately select the "Configure accounting parameters" item.
After this, a window will open and in it select the “Data exchange” item. Click on Allow the use of data exchange, and then click the “Record and close” button.
After we enable data exchange, a new item “Data exchange” should appear on the left side of the window. Click on the “Data exchange” item.
When the window opens, click on the “Create” button. Select the item “Create an exchange in a distributed information base.” After this, the wizard window for creating a Distribution Information Base will open.
We look for the “Next” button in the window that opens and click on it, after which we move on to another window. The article you are viewing depicts data exchange through a local or network directory.
Find the exchange directory and check the box next to “Compress outgoing message file.” Then click on “Next” and skip the next two windows (we do this because in this article we will not consider exchange via FTP and mail).
Click "Next".
We call the name for the data exchange plan as convenient for you, I chose, for example, “Exchange_With_Peripheral_Base”, you can set your name. Then we check that the “Main method of data exchange” is “Exchange through a local or network directory” and click “Next”.
After we check the contents of the current window and click “Next”.
In this window we also do not change anything and click the “Finish” button.
Specify the path to the folder for creating the Distribution Information Base. You need to specify it in UNC format, for example "\\rib\1Cv8.1CD". If everything is correct, then a distributed database file will be created in the specified folder.
Now we set up automatic exchange and its schedule. To do this, go to the "Administration" tab and select the "Data exchange" item and double-click on the existing line in the list of data exchanges:
In the window that opens, click on “Data exchange scenarios”:
In the window that opens, click on the “Add” button:
In the window that opens, click on the line “Every day, every 900 seconds.”:
In the window that opens, set the necessary parameters:
We set the parameters so that the exchange is performed daily from 00:00:00 to 23:59:59 with a break of 30 seconds. This is done in order to show that the exchange is carried out in the attached video; you can set other parameter values for yourself. In the previous window, click on the “OK” and “Save and close” buttons.
The configuration of data exchange for the central node has been completed, and the peripheral node is being configured in the same way. It is necessary to change the 1C launch shortcut by adding the launch parameter "/CDoScheduledJobs" so that the exchange is performed automatically.

Setting up automatic exchange on a peripheral node is no different from setting up on the main node. If you configure the exchange script, the exchange will start automatically when a user with admin rights logs in.

The configuration in the distribution is updated as follows: manually, first the changes are made in the central bank, then we upload it and transfer it to the periphery. The automatic exchange usually does not work.

The technology of distributed information bases (RIB) allows you to create a geographically distributed system based on 1C Enterprise configurations. This allows you to have a common information space even with those departments that do not have a reliable communication channel, combining high autonomy of nodes with the ability to quickly exchange information. In our articles we will look at the features and practical implementation of this mechanism on the 8.2 platform

First of all, let’s ask ourselves: why autoexchange? Modern technologies, combined with inexpensive and fast Internet, make it possible to organize remote work without any difficulties. The choice of methods is as wide as ever: RDP, thin and web clients, connecting networks using VPN - there is a lot to think about. However, all these methods have one significant drawback - a strong dependence on the quality of the communication channel.

Even with ideal operation of the local provider, it is impossible to guarantee 100% availability of the communication channel. Problems with the backbone provider, lack of power supply, physical damage to the communication line and many other factors make this task insurmountable. At the same time, the inaccessibility of the information base at a remote warehouse or retail store leads to quite significant losses. And finally, let’s not forget that there are places (for example, industrial zones on the outskirts of cities) where providing a high-quality communication channel is expensive and/or problematic.

The RIB mechanism allows you to get rid of these shortcomings; each department has its own copy of the information base with which you can work autonomously even in the complete absence of communication with the outside world. And the small amount of transmitted information allows you to use any communication channel, including the mobile Internet, for exchange.

RIB on platform 8.2 is not something fundamentally new, representing a further development of RIB platform 7.7, only now this technology has become more accessible and simpler. Unlike the RIB component, which had to be purchased separately, the RIB is an integral part of many standard configurations and works entirely in user mode, allowing you to do without the Configurator even at the setup stage.

At this point it would be time to move on to the practical part, but we will have to make one more digression. The fact is that the transition to the 8.2 platform, which seems to have already happened, in fact led to the emergence of two types of configurations: based on a managed application, “native” for the 8.2 platform, and adapted from 8.1, continuing to use outdated technologies and mechanisms. Since a significant part of the configurations (Enterprise Accounting, Payroll and HR Management) are adapted or transitional, they cannot be discounted, so the first part of our article will be devoted to these configurations (essentially the 8.1 platform), while in the second we will examine setting up auto-exchange for configurations based on a managed application (platform 8.2).

Let's consider a practical task: setting up automatic exchange via FTP for the Enterprise Accounting 2.0 configuration. Despite the fact that RIB allows you to exchange using email or file shares, we recommend using FTP as the simplest and most reliable method of communication. You can read how to set up your own FTP server, or you can use the FTP service of any hosting provider.

First of all, we need to configure exchange nodes. To do this, launch the configuration with administrator rights and select Transactions - Exchange Plans.

In the list that appears, select Full plan or By organization, if records are kept for several companies in one database and the exchange needs to be made only for one of them. In the window that opens, there is already one node - the central one, we need to edit it by indicating the code and name.

Then we will create another node for the branch, filling it in the same way (to add, click the green circle with a plus). The next step is to create an initial image for this node, which is a ready-made information base in file mode. To do this, right-click on the desired node and select from the drop-down list Create a starting image.

Now let's move on Service - Distributed Information Base (DIB) - Configure RIB nodes.

In the window that opens, click the button Add and configure a new exchange by specifying the remote host, exchange type (via FTP) and server connection parameters.

Bookmark Automatic exchange allows you to set up an exchange schedule, exchange by events (start and end of work, etc.), these settings are made for the user on whose behalf the exchange will be performed, so make sure he has rights to exchange data.

Don't forget to specify the node prefix for document numbering (otherwise you will receive different documents with the same numbers) in Tools - Program Settings; here you can also configure some other exchange parameters. On the same tab, you should select a user to perform exchange tasks; if you do not do this, the schedule will not work. Remember that the exchange will only be made if the user is logged into the program.

This completes the configuration of the central node; now you need to make similar settings for the peripheral node, connecting the initial image as an existing information security system. After which you can start exchanging data. To control you should use Communication monitor, it allows you not only to monitor the success of the upload/download, but also shows any collisions that have arisen or delayed movements (if the user who made the exchange does not have enough rights to perform any actions in the database). The presence of this tool allows you to quickly and effectively solve various types of problems that arise during autoexchange.

At this point, the exchange setup can be considered complete and you can begin working in distributed mode. It is worthwhile to dwell specifically on updating or making changes to the configuration. These actions are only available on the central node; all changes made will be automatically propagated to the peripheral nodes during the next exchange. To make changes automatically, the peripheral database must be in exclusive mode, otherwise you will need to run Configurator and execute Updating the Database Configuration manually.

In 1C 8.3 or in 1C 8.2? Setting up a distributed infobase. Step-by-step instruction.

Information base distribution is used when it is necessary to maintain joint records in databases that cannot, for various reasons, have a physical connection. An example would be accounting in one company that has a division in a large city or small village without the ability to connect to the Internet. Or in some special cases of periodic need to simultaneously work with one database in the office and outside the office, for example at home. In such and similar cases, the use of a distributed information base (DIB) is justified and necessary.

In this article we will look at organizing the distribution of one information database in the 1C Accounting for Russia version 8.3 configuration through a local or network directory. In version 8.2 1C, this instruction will also be useful, because describes essentially one process with significantly small differences.

==== Setting up for the main base ====

Having opened 1C 8.3 in the “Enterprise” mode, let’s go to the “Administration” section. In version 1C 8.2, to get started, you need to go to the main menu “Service” - “Distributed Information Base (DIB)” - “Configure RIB nodes”.

Next, we will consider the process in the context of information security version 8.3. So, going to the “Administration” section, select “Program settings”. In the settings, go to the “Data Synchronization” section. Here we check the box “Use data synchronization” and specify the database prefix. Let us indicate “CB”, implying a central base.

After this, the “Data Synchronization” item appears in the right menu. Let's choose him. In the child window that opens, click the “Set up data synchronization” button. In the drop-down menu, you can select settings for different synchronization use cases. We select “Distributed information base...”.

For general development, familiarize yourself with the contents of the next window and click “Next”.

In the next window, fill in the directory through which the . We will specify data compression to reduce the size of the upload, and you can immediately specify a password for the archive with the data. It is important not to forget him. Confirm the filling with the “Next” button.

The next two windows are designed to specify settings for cases of exchange via an FTP server and via email. As stated earlier, we are considering the exchange method through a directory, so we are skipping the settings for FTP and email.

The next window is intended for specifying exchange parameters in the peripheral database part. Let's indicate its name and prefix. Next is the “Next” button.

Let’s check the exchange parameters we have created and confirm their correctness with the traditional “Next” button.

The necessary set of settings for exchange will be automatically created. It will take some time.

Important! Creating the initial image for the slave node takes a significant amount of time. The size of this significance depends on the computer resources and the volume of accounting in the main database.

Let's assume that we decide to create an image. After clicking on the “Finish” button in the previous window, we will enter the settings to create an image of the slave information security. We will consider the simplest case for local operations. To do this, indicate the necessary details in the window that opens. Let us pay special attention to the “Full name of the file base” parameter. It must be specified in full UNC format, which requires the formation of a local path in a “network” format. For example - “\\Server1C\Databases\RIB”. To the specified path we will add the name of the database file - 1Cv8.1CD.

After clicking on the “Create initial image” button, the process of generating an image for the slave database starts.

After the process is completed, a database file will be created in the specified directory. This newly created database needs to be configured before full use.

==== Setting up for a peripheral base ====

To do this, you need to connect it to 1C. You will find how to do this in the instructions in our article - After connecting, you need to launch the new database in configurator mode and create users. Next, the information security needs to be launched in 1C “Enterprise” mode.

If, for some reason, the creation of users needs to be postponed to a later time, after connecting, you can simply launch the database in 1C “Enterprise” mode. You will be prompted to create an “Administrator” user, agree to it, and the initial filling will be done.

Then you need to continue setting up pairing with the main base. This setting is similar to that discussed above for the main database.

A setup for communication with the main base will be created.

============================================

So, now we have created the main and peripheral bases. Synchronization settings have also been created in each of these databases. Now you can move on to editing these settings and bringing them into a suitable form. You can create automatic exchange rules or perform the exchange manually.

Let's do this in the main database. The peripheral base is configured in the same way.

Editing can be applied to data synchronization rules and schedules.

By clicking the “Configure” button in the “Data synchronization schedule” section, you need to edit the scripts to automatically schedule the work of uploading/loading data for the selected database. You don’t have to edit it, just agree with the default options.

To edit the parameters, just click on the link with the automatic schedule data. And then we edit the temporary parameters for launching tasks. By going through the bookmarks you can change both the time and the dates and days of the week of the launch.

By clicking the “Run task” button in the main script window, you can manually run the task.

By clicking the “Configure” button in the “Data synchronization rules” section, you can perform operations to change task launch scripts, as well as view the log of uploads/downloads. The latter is quite important for administering access and monitoring the regularity of exchanges.

Having finished creating and editing scripts for automatically starting distributed database exchange, you can proceed to uploading and then loading data.

At this point, the configuration of the distributed bathhouse database for the central and peripheral nodes is basically completed.

Download illustrated instructions

Distributed information base. Step-by-step instruction
Distributed Information Base (RIB) 1C:Enterprise
Creating a distributed infobase and setting it up
how to set up rib in 1s 8.2
How to set up a distributed information base in 1C
How to set up in 1C
How to set up in 1C
Setting up a distributed information base (RIB) in 1C
Example of setting up RIB for 1C:Accounting 8
Creation of a distributed infobase and configuration

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 the methods of creating a peripheral database by restoring a copy of the central database from a backup or attaching files of a copy of the central database for SQL format and executing the script are given. 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.