How to work with the 1c configuration repository 8.3. Working with the configuration repository

For group configuration development in the 1C: Enterprise 8.3 system is used configuration store... Developers can access the configuration storage over the local network (database files are located on a shared network resource), using the protocol tcp or http... For the last two options, you need to install configuration storage server... The configuration repository server, in turn, is a network service that "listens" to the port by default 1542 and provides interaction of client applications (configurator) with the configuration store database. One service can serve multiple configuration stores. About the installation of the 1C: Enterprise configuration storage server 8.3 (also true for the version 8.2 ) in an OS of the Windows family (in the current example -) and will be discussed in this article.

1. Setting up the database directory of the configuration storage

The configuration repository server must be installed on the same computer where the repository database files will be located. Therefore, first of all, we will define the central directory of the server, which will store the files of all storages that this server will serve. Let it be a directory within the framework of this article. C: \ 1C_BASE \ repository \... You should also define the Windows account from under which the corresponding service will start. You can create or use an existing Windows account. In this example, we will use the local user USR1CV8 with password UsrPass8... Required for this user to the central directory of the configuration repository server.

2. Installing the configuration repository server files

At the time of this writing, the configuration store server existed only as a 32-bit application. Therefore, to install the server files, you need a 32-bit distribution kit of 1C: Enterprise 8.3 for Windows. Run the file 1CEnterprise 8.msi from the distribution kit of 1C delivery. On the component selection page, select the component " 1C: Enterprise configuration storage server"(1C: Enterprise configuration repository server), and also remember the component installation path.

3. Registering and starting the configuration storage server service

The installation program only copies the configuration repository server files to the specified directory. Registration of the corresponding service must be done manually by executing a command of the form:

Crserver.exe -instsrvc | -rmsrvc -usr<пользователь>-pwd<пароль>-start | -stop -port<порт>-d<каталог>

Configuration repository server startup parameters crserver.exe are similar to:

Start parameters of the 1C: Enterprise configuration storage server
Parameter Description
-port<порт> Storage server working port. The default is the port 1542 .
-d<каталог> Root directory for configuration stores. The default is the directory % APPDATA% \ 1C \ 1Cv8 \.
-instsrvc Registering the warehouse server as a service.
-rmsrvc Removing the registration of the warehouse server as a service.
-usr<имя>
-pwd<пароль>
Username on whose behalf the service will be registered. This user must have the Log on as a service right. In addition, he must have the rights to read the directory of executable files of the corresponding version of the 1C: Enterprise system and full rights to the root directory of the configuration storage (directory % APPDATA% \ 1C \ 1Cv8 \ or whatever directory is specified in the parameter - d) and the password for this user.
-start Start the warehouse server service.
-stop Stopping the storage server service.

Let's register a new service using the program Windows PowerShell, which can be run by running the command powershell(for this you need to press the key combination Win + R, in the appeared window “ Execute"(Run) enter the command name in the" Open"(Open) and click" OK") Or by clicking on the corresponding shortcut in the taskbar.

In the opened Windows PowerShell console, for the convenience of entering further commands, go to the directory bin directory with installed files "1C: Enterprise" by executing the command

Cd "C: \ Program Files (x86) \ 1cv8 \ 8.3.5.1088 \ bin"

Then, within the framework of this example, we will run the command

. \ crserver.exe -instsrvc -d C: \ 1C_BASE \ repository -usr. \ USR1CV8 -pwd UsrPass8

and start the service by executing

. \ crserver.exe -start

Let's go to the service snap-in (which can be started by running the command services.msc) and make sure that the service named 1C: Enterprise 8 Configuration Repository Server registered and launched.

5. Creating a new configuration store

As I said earlier, one server can serve multiple configuration stores. The database files for each of the repositories must be located in a separate directory in the central directory of the configuration repository server. Thus, to create a new repository, create in the directory C: \ 1C_BASE \ repository \ folder Accounting in which the files of the new configuration store will be located.

Then, to create and connect to this storage, you will need to use the line tcp: // WIN2012 / accounting, where WIN2012- network name of the computer on which the service is installed, or a string tcp: //192.168.0.10/accounting, where 192.168.0.10 , respectively, the IP address of this computer. More details about creating a new repository can be found in the article "".

It will also be possible to connect to the storage created in this way bypassing the server, for example, along the path C: \ 1C_BASE \ repository \ Accounting on the current computer or along the way \\ WIN2012 \ repository \ Accounting if you set up a shared directory C: \ 1C_BASE \ repository on this server.

Did this article help you?

Nafa 647 14.01.10 02:27 Now in topic

The article is useful.
There are really a lot of non-obvious things in the work of the repository, so my additions:
1. If several programmers work, then as an option,
A business day usually starts with the following:
We launch our database in the configurator, on the root of the configuration with the right mouse button - get from the repository, turn on the "recursive" checkbox, click OK. After that, we get into the configuration everything that others have worked out from the repository. WE DO NOT UPDATE THE DB itself !!!
Next, we want to "compare the configuration with the database configuration" - and we see a list of all the changes made by other programmers in the group for the previous day. If you have questions about the changes, we turn to the person who made them.
After everything has been sorted out, we save it to the database.
Why not compare with the storage configuration - firstly, so that the objects you are working on yourself are not shown, and secondly, it works faster.
2. In the middle of the day: urgent changes (for dynamic updates) are sent to the repository immediately. Not urgent - after we change all related objects. (see explanation below)
3. At the end of the day (and if you need to do a complete update of the database, then before it) we hand over everything we can to the repository.
This is not a mandatory order, but it is very convenient.

4. Why don't we place it right away:
because the integrity of changes is controlled by 1C only where there is a link. That is, if, for example, you have made a reference book "Client cars" and added a link to it in the "consignment note", then you can place the "Consignment note" in the storage only after (or simultaneously) with the reference book "Client cars". But if, for example, you used this directory in a common module procedure, which is called when posting an invoice, then this common module can easily fit in the storage without placing a directory. If after that another programmer receives this module from the storage, then the invoices will no longer be posted in its database. (And if you update the main base, then they will stop there too).
And that is another good case - since there is just an error. But if, for example, you changed the type of the attribute in the document from a line to text and in the procedure of the general module there was a check If the Attribute = "1" and became If the Attribute = 1 and the module was placed in the storage and the document was not, then there will be no error (hello, no type control), which means that for those who receive such a module, the documents will be incorrectly carried out (and it's good if this is not the main base). Therefore, it is better to submit changes to the repository in a "full package" (all objects changed on one topic), if you need something for another task, you can immediately grab it on a new one or simply "leave it captured" by placing it in the repository.

In this regard, I did not quite understand:

If there are a lot of programmers, then everyone's changes must be sent to the Repository one by one, BEFORE unloading everyone's work into external files with the local database configuration and (if the merging is done from different workstations), not forgetting to UPDATE the local databases from the Repository before each merge - to the latest version , with the changes of previously connected comrades present there ..

Strange, there were no problems when several people placed changes at once, except that a little slowed down. That is why the capture of objects is provided so that 2 people do not fix the same thing at once. Moreover, it was noticed that: if 1 developer changed the document, say "Advance report", and then did not do the second "receipt", but immediately captures it (for example, the object has just been placed in storage), then 1C will track it and give it to him already a new - modified version. (It happens so cool - you look at the document - 5 details, you grab - already 15).

And why to unload work in external files also did not understand.

4. It is easier to create copies of the database for programmers not by 1Sovy loading / unloading (since it requires exclusive mode and not very fast), but by restoring a cheeky backup or simply copying the base on a cheekbone.

5. If you need to add a new object (document, reference book, etc.), then grab the configuration root, add it, add a minimum of details (completely "empty" objects are not always saved), hand over the root to the storage (this object will also surrender at the same time) and pick up the object again. (In order not to keep the root captured for a long time - others need it too).

6. If you want to fix the permissions on an object, you have captured it - and the permissions are still unavailable - grab the appropriate role.

7. Since debugging is best done on the most recent data, the production databases need to be updated. To do this: put all the changes in the repository, disconnect the base from the repository, rewrite the main base on the cheekbone (from a backup or just copy), reconnect it.

8. When we do "get everything from the repository" (item 1), it happens that 1c issues a bunch of messages and then writes that "failed" (the list of objects changes in this case). Means for a long time did not receive changes. It's okay, we press OK on a new one and so on until it works as it should.

9. Sometimes 1C refuses to save the changes received from the repository, and the message is absolutely indistinct. The culprits are usually "registers of information". We find out which register of information the structure has changed, delete all records from it in our database, after that everything will be updated as needed.

10. Since the working bases are made from the main one, the names of the configurations coincide and it is easy to confuse them, and then confusion begins when the user says that he has 100 rubles in his report, and you have 100,000 rubles. As an option, we add a line to the application module that checks what kind of base it is when starting the program and, if not the main one, displays it in the header of the 1C program (for example, "WORKING BASE OF PROGRAMMER IVANOV")

11. When the base is connected to the storage, but at startup it was not possible to connect to it for any reason, the message "Failed to connect, disconnect from the storage" may appear (and you have captured objects) - here ANSWER NO. But if you accidentally answer "yes" then - do not try to connect on a new one !!! First save the config to a file !!! Since when we connect to the storage, the entire database configuration is replaced with the storage configuration. After that, load the changes from the saved file and move on.

Sooner or later, every developer tries to improve his or her life. It's not about its material component, I'm talking about simplifying work. The more you practice working on real projects, the more you realize how to do your work more efficiently and correctly.

Today I would like to talk about the use of configuration storage in the development / refinement of applied solutions. I do not know why many 1C developers bypass the use of storage capabilities. Especially, I do not understand those who are working on the development of one configuration with a whole team. Without a configuration store, there is (IMHO) absolutely nothing. No, you can certainly engage in perversions like copying one configuration to all developers. Everyone starts to work and realize their part. Upon completion of development, each of the developers must synchronize their config with the one that will be supplied to the end client.

With this approach, it is quite problematic to keep track of the relevance of the conference. As soon as two or more developers start working on two related tasks, hell begins when combining the results of their work. Chances are too great to overwrite something or not combine well. During my practice, I came across such a situation several times and after another full bump I decided that it was impossible to live like this anymore.

What is a configuration store

Fortunately, before I got acquainted with the 1C: Enterprise 8 platform, I already had quite good experience in development in other programming languages ​​(Delphi, PHP). Therefore, words like SVN (Centralized Version Control System) were not a novelty for me. Who has never encountered SVN, I recommend reading the corresponding article on Wikipedia - http://ru.wikipedia.org/wiki/Subversion. Believe me, the thing is cool and it greatly simplifies the software development process.

So now let's get back to our repository. Configuration storage is a tool of the 1C: Enterprise platform that allows you to organize group development of an applied solution. The configuration store (hereinafter HC) provides developers with a version control system for the solution being created and flexible options for controlling the changes made by developers.

In what cases can HK come in handy?

Before listing specific examples, I would like to summarize right away. Of course, HK will be most useful during team development. However, nothing prevents you from using it purely for yourself. I have been developing on the 1C: Enterprise platform for almost five years and over the years I have repeatedly had to deal with unforeseen situations when the use of HC literally saved me from the nightmare of any developer - rewriting previously written code. Now I try to use the services of a configuration store for each of my projects. Why? And at least this:

1. Storage history. Perhaps this is one of the most important functions for me. During the development of a solution using HC, the formation of a history of configuration changes will automatically occur. For example, the configuration was updated several times in one working week. All these changes are accurately recorded, and the history is updated with versions. If you wish (or if a hopeless situation arises), you can always look at the list of versions and, if necessary, roll back. For example, on Monday, the correct configuration changes were made, and on Tuesday, a new developer significantly screwed up and posted his upgrades. The result is a configuration with a key code.

You can, of course, give the young programmer a header and then try to restore it with pens, or it is better to press a couple of buttons and restore the previous version of the config, or simply roll back the changes made by the would-be developer.

2. Reporting. You can scroll the report at any time and see who and when (as well as in which configuration objects) made changes. This can come in handy when your colleagues shrug their shoulders and try to prove: “Nasyalnika, this is not us! It broke itself! ”

3. Remote development. HC is irreplaceable if the application solution is developed by geographically distant programmers. I think there is no need to explain this.

4. Minimization of emergencies. Several times I witnessed (because of my “youth” and myself managed to fall into this trap) when the screws of the developers broke. Of course, all the latest changes were on those same screws and they irrevocably flew away into oblivion. "What about backups?" - you will say. No way! Many developers don't like to bother with this. No, only full extremists do not make backups at all, but in my practice I have met very few developers who make backups several times a day. HK solves this problem elegantly. In fact, the developer only needs to press one button and all his developments will be immediately transferred to the repository.

5. Access control. Well, there is no need to explain too much. HC allows you to configure access control for developers.

Repositories are different

Initially, HC worked only through a shared resource (in version 8 .. It was not very convenient, because if you wanted to organize access to the storage from the outside (for example, via the Internet), there were problems. Starting from version 8.1.11, it became possible to deploy network You can work with them both via tcp / ip and http, which will be very useful when organizing access to the storage via the Internet.


Figure 1. Diagram of the storage device

Trying to deploy HC

So, let's say that you are interested in the idea of ​​using HC and decided to try deploying it for your project. You already know that the storage can work through a shared network resource, and over a network using the tcp / ip protocol. In this post, I'll take a look at deploying storage over a share, and next time we'll look at the network option.

So, the first thing you need to do is prepare the base of your project. You can have it anywhere. If you decide to deploy HC for your live project right now, then do not be lazy to make a backup copy. Anything can happen and it's better to play it safe once again.

Create a shared folder on your computer (or directly on the server). Make it common and define users who will be able to work with it. By users, I mean your fellow developers.

The next step is to open your database in the “Configurator” mode and proceed to the “Configuration” -> “Configuration storage” -> “Create storage” menu (see Figure 2).


Figure 2. Creating a configuration store

Immediately after clicking the "Create storage" button, you should see a window as in Figure 3. In it you need to select a previously created shared folder or enter the address of the remote storage. Since we agreed to create a repository based on a share, this window will indicate exactly the path as a folder.


Figure 3. Choosing the location of the HC

As you specify the folder - click on the "Next" button. Before you have time to blink an eye, the storage creation wizard will display a window for creating an administrative account in front of you (Figure 4). By default, you are offered to use “Administrator” as the name. It is clear that nothing prevents you from changing it. In general, enter the desired values ​​and click "OK".


Figure 4. Creating an administrator account

Here your 1C'ka should think for a few seconds and then offer to connect to the created storage. Answer “Yes”. Congratulations, you've created your first configuration repository.

Pay attention to the "Configuration" window. Starting from the very root (this is where the name of the configuration is written), small locks appeared on the right side (see Figure 5). This lock means that the object is currently in the configuration store and you cannot make changes to it. If you need to work with any configuration object, you first need to grab it. I will tell you how to perform this and many other operations for working with the storage in the next note, which will appear on the site very soon.

In 1c version 7.7, joint development or configuration revision was a real torment. In order to maintain one configuration, even together, it was necessary to make two copies of the current base, then, after the changes were made, manually transfer the changes from the configuration of one copy to the configuration of the other. Only then could the main supported configuration be updated! The situation was aggravated by the absence of subsystems.

In the eighth version of 1c, for joint development, configuration store... Working with the repository is as follows:

  • Create a repository

Select in the menu "Configuration" -> "Configuration storage" -> "Create storage ..."

We indicate the path to the storage directory. (The directory must be accessible to all developers!)

After the repository is created, go to the menu item "Configuration" -> "Configuration repository" -> "Administration" in order to create users for developers

And create users

  • Connecting developer configurations to the configuration repository


choose menu item "Configuration" -> "Configuration storage" -> "Connect to storage ..."



Since our copies of the main database are still identical, boldly press the "Yes" button and specify the path to the storage, username and password

We are waiting for the comparison of the configuration with the storage.

If everything went well, a lock icon should appear to the right of the configuration objects in the object tree.

  • Working with the configuration repository

By default, all configuration objects have a lock icon. In order to change the configuration object, you need to capture it, that is, select the "Capture to storage" item in the context menu of the object

specify capture settings

The object in the configuration tree will have the icon

If the object is captured by another developer, then the object in the configuration tree looks like this

After the necessary changes have been made, the object should be placed back into the repository with the changes made. In the context menu of the configuration object, select the item "Place in storage ..."



  • If you want to cancel the changes made and release the object from capture, then select in the context menu of the object, the item "Undo capture"

  • If you need to restore an object from storage, then select the "Get from storage ..." item in the context menu of the object. In this case, the changes made while the object was captured are lost.

  • You can also view the version history and compare the captured and modified object with the object in the repository.

  • After the work in the copies is completed (or some intermediate stage is completed), you can update the configuration of the main base; for this, you need to select the item in the menu "Configuration" -> "Configuration storage" -> "Update configuration from storage" or "Configuration" -> "Configuration repository" -> "Compare / merge configuration with repository".

In the second case, a "softer" configuration update will occur, that is, it will be possible to view a report on the differences between the objects of the original configuration and storage.

Enjoy your development!

1C company releases many software products and constantly improves their internal structure. But the number of various errors that 1C programmers and administrators have to face shows that work in this area will never stop. Some of these errors are minor and rare, but there are "classic" shortcomings that are familiar to every experienced professional. The latter includes the well-known error "Invalid data store format" and it is desirable to be able to solve it.


Resolving Data Warehouse Format Error

To encounter this error, it is not at all necessary to commit serious logical errors in the code or to delete the main module. Often after updating the configuration, opening processing, a power outage or restarting the computer, this unpleasant surprise occurs when 1C starts. If rebooting doesn't help, don't panic - this common error has simple solutions that might help. We will analyze them according to the degree of complication:


In addition to the moment the configuration is started, the error "Invalid data storage format" can also be detected when opening an external processing. In this case, the most important thing is not to start 1C, since at startup the system overwrites temporary files in the TMP directory. It is in it that you find our processing - a file named "v8_ *" and the extension tmp. If there are a lot of such files, then in order to understand which one is our processing - change the extension to epf and try to open it through 1C.

If you have already started 1C and the files are overwritten, then try to carry out similar actions on another computer where processing was started. Or use utilities to recover deleted files on your hard drive.