Manual for updating atypical. Manual for updating atypicals Updating the main configuration

This technique allows you to debug and modify the manager module in external processing without the need to re-save the configuration and restart the base

Formulation of the problem

Let's say we are modifying a base with a very heavy configuration. Saving and / or restarting after saving takes a long time.
Let there be a manager module for some object in our configuration. This manager module has an export method from which the rest of the procedures are called.
It is necessary to improve this manager module. In this case, it is required to minimize the number of database restarts after each change to the code during the debugging process.

Solution essence

Let's copy all the code of the manager module into external processing
- Add the ability to redirect calls of export methods of the manager module to external processing (in the simplest possible way)
- We will enable / disable redirection from the debugger using the conditional stop mechanism

Step 1.
I suggest adding the following code to the beginning of the method, which is the entry point:

// Manager module of some configuration object Procedure Print (Parameters) Export // ++ debugging Variable Debugger; If the Debugger<>Undefined Then Debugger.Print (Options); Return; EndIf; // - debug Report ("This is a call from the manager module"); End of Procedure

Step 2.
Next, we create a service universal external processing, for example, in some folder on the server. Let's call it Debugger.epf.
In this processing, we will describe a short universal export function with the following content:

// Processing Unit Debugger.epf Function SetDebugModule (Debugger, UnitName) Export Debugger = ExternalProcessing.Create (PathTo ExternalProcessing (UnitName), False); Return False; EndFunction Function PathToExternalProcessing (ModuleName) Return CurrentDirectory () + ModuleName + ".epf"; EndFunction Function CurrentDirectory () Export File = New File (ThisObject.UsedFileName); Return File.Path; EndFunction

Step 3.
Let's create an external processing in which we will write our code. We copy the entire code from the manager module into the module of the object of this processing.
Let's save it in the same folder as Debugger.epf. Let's set a name for this processing, for example, such as Processing.Invoice Printing.Manager Module.epf.

// module of external processing object Processing.PrintAccount.Manager.epf Procedure Print (Parameters) Export // ++ debug Variable Debugger; If the Debugger<>Undefined Then Debugger.Print (Options); Return; EndIf; // - debugging // ++ fixed // Report ("This is a call from the manager module"); Report ("This is a call from external processing"); // - fixed EndProcedure

Step 4.
Set a conditional breakpoint in the manager module. Add the following code to the condition:

ExternalProcessors.Create ("C: \ Debug \ Debugger.epf", False) .InstallDebugModule (Debugger, "Processing.PrintInvoice.ManagerModule ")

Step 5.
We run the test case. The condition check will be called at the breakpoint. In this case, the object of the created external processing Processing.PrintInvoice.ManagerModul.epf will be assigned to the Debugger variable. This will cause the condition If the Debugger<>Undefined Will then execute and the call will be forwarded to external processing.

Step 6.

We refine and debug the code in external processing, while not wasting time on restarting after each save.

After completing the improvements, we replace the code in the manager module with the code from external processing (completely).

Don't forget to disable conditional breakpoints.

Before placing it in the repository, you can delete the debug part in the manager module.

Application area

In this way, you can debug and modify modules of managers of any objects and common modules (server).
A similar technology is used to debug object modules, but there are a number of nuances and limitations.

Files

I attach external processing Debugger.epf, which, in addition to the function described above, has several other useful features. Including is able to create an empty template processing with a name corresponding to the object being modified

Processing is opened in guided and regular application in any configuration.
Tested on 8.3 platform in compatibility mode with 8.2.13. That is, it should work under 8.2 and 8.3

Personal experience: how to quickly and inexpensively update the changed configuration

It is very dangerous to update the configuration for several releases at once. The fact is that after each configuration update, the infobase is updated in the "1C: Enterprise" mode. Therefore, if you update only the latest release, infobases may not correspond to the latest configuration. In the article Dmitry Rudakov, specialist of the company CJSC "Siberian Agrarian Group", shares personal experience for a one-time configuration update for 12 releases.

Checking the configuration change mode

Let's imagine the following situation. The developers of "Manufacturing Enterprise Management" (hereinafter - SCP) in release 1 (release numbers hereinafter are assigned conditionally) to the dimension (indicator) of the calculation register assigned the type "ReferenceLink.Physical Person" with the name "Individual". In release 2, they added one more dimension - "Employee" with the type "ReferenceLink.Employees". When you start "1C: Enterprise" processing is turned on, which fills in the "Employee" dimension in the manner corresponding to the dimension for "Individual". And then in release 3 the developers of "1C" deleted the "Physical Face" dimension and left only the "Employee". If you update the configuration from release 1 immediately to release 3, you can clear the entire calculation register.

And if the configuration is supported with the ability to change, and regulated reporting is generated in the same database, then it is necessary to update the configuration for each release, which can be very expensive in man-hours. For example, updating a heavily modified "SCP" for 1 release can take 30 hours of working time for an experienced technician.

Therefore, before proceeding with the update, you need to determine: are you working in a typical configuration with the ability to change or in a configuration without the possibility of modification? To do this, go to the configurator, where in the menu perform the actions "Configuration - Support - Configure support".

Fig. 1. Calling the configuration support window

If "Supported" is installed, then this configuration is typical, and if "Changeable is enabled" - the configuration is most likely changed (at least, this feature is included). The third state is "The configuration has been removed from support". The various configuration states are shown in Figures 2, 3, 4.

Rice. 2. Typical configuration without the possibility of changes

Rice. 3. Typical configuration with the ability to change enabled

Rice. 4. Configuration removed from support

Algorithm for updating changed configurations

Recently I was faced with the task of updating the changed configuration "Trade Management", release 10.3.13.2. The configuration was changed as a result of the merger with the industry solution "BIT: Car Service Management 8" and was continuously refined for two years. Now the configuration needed to be updated to release 10.3.25.1, that is, for 12 releases. I have broken down the entire update procedure into several stages.

Stage 1. Estimation of the cost and timing of the renewal procedure

Before proceeding with independent work, I decided to get an independent assessment from experts in this field. The only company that has the ability to update changed configurations by automated methods is 1C-IzhTiSi LLC. I contacted the specialists of this company with a request to estimate the cost of updating my configuration. To estimate the time and cost of the work, I have provided the current configuration in need of updating. A day later, I received a letter with a report.

Report on the results of the assessment of the cost and timing of the configuration update:

Configuration: Trade Management, Revision 10.3
Current config version: 10.3.13.2
Update to version: 10.3.25.1
Number of modules updated: 1 847
Control releases: 8

The results of the assessment surprised me, since the company's website indicated the value of the share - 1000 rubles. for one release update. 1C-IzhTiSi comments:

"The cost of updating for each missed release is not more than 2,000 rubles. Now the promotion is taking place, so the cost does not exceed 1,000 rubles. But the final price of services is determined based on the results of the assessment of labor costs for the update and may be below 1,000 rubles / release."

I also clarified how the releases needed for the update were selected. In response to my question, I received a screenshot that clearly demonstrated this (Fig. 5). The "Version number" column indicates the version of the configuration to which you want to upgrade. The column "Version upgrade" indicates from which release the upgrade is possible. As a result of the assessment, the number of required updates was reduced to 9.

Rice. 5. Selection of releases that must be used for correct configuration update

After studying the report "1C-IzhTiSi" I calculated the personal time spent on the same amount of work. Each update procedure takes me approximately 6 hours. Therefore, the total time spent is 56 (9x6) working hours, which is approximately seven working days. In addition, there is a possibility that after the update some shortcomings will come to light: for example, the user will complain that the necessary changes in the configuration have been lost, and then the time costs will seriously increase. Meanwhile, the specialists of the 1C-IzhTiSi company propose to do the entire volume of work in three to four working days. So I decided to use their services.

Now I will briefly explain what exactly was changed in the configuration.

Heavily modified objects. These are objects in which many typical properties have been changed. The adjustments are complex. The details of the object have been added to the tabular section, displayed on the form of the object and on the form of the list. Added handlers for added details in forms. Changed the standard mechanism for document posting or movement set recording for the register.

Strongly modified documents:
"Order to the supplier";
"Moving goods";
"Requirement-waybill";
"Receipt of goods and services".

Heavily changed registers:
"Consignments of goods in warehouses";
"Goods in warehouses".

Significantly changed objects. Objects in which details are added, either the forms of the objects or the modules of the object are changed (as a rule, document posting is atypical).
Document "Receipt cash order";
Register of information "Nomenclature components";
Information register "Written off goods";
Common modules.

Slightly modified objects. In the objects, only the forms have been changed and the requisites have been added.

References:
"Types of nomenclature";
"Contracts of contractors";
"Contractors";
"Nomenclature";
"Item price types";
"A number of information registers".

In the "General" section, subscriptions to events, layouts, roles, general modules have been changed. Almost everything has been changed by an industry decision.

Stage 2. Removal of confidential information

Before providing the 1C-IzhTiSi employees with an information base for testing, it is necessary to delete confidential information in it. For such cases, 1C recommends using the "Change of confidential information" processing, which is not very widely known.

Processing "Change of confidential information" is designed to selectively change or clear information in the infobase.Processing can be used to prepare information base before submitting for testing, where it is necessary to hide (clear, change) some information.

Processing Changes to ConfidentialInformation.epf is on the ITS disk in the 1CIts \ EXE \ EXTREPS \ UNIREPS81 \ UpdatePrivateInformation directory. Also this processing can be downloaded from the link: http://its.1c.ru/db/metod81#content:1644:1.

Naturally, confidential information in each company is different, but I would like to draw your attention to the data that most likely needs to be changed:

• Directories: Individuals, Contact persons, Contact persons of counterparties, Counterparties, Price types.
• Information registers: Passport data of an individual, full name of individuals.

Your list is likely to be broader, but this is the most common data. Changing them is unlikely to affect the ability to test your infobase. You can also group processing delete all those objects, work with which service company not expected.

Stage 3. Getting the update results

Three days later, I was provided with the cf files and comprehensive instructions on how to install them. For control releases, cf files are provided that cannot be used for user experience, as only metadata is updated in them. They are intended only for correct updating to the latest version.

Based on the result of the work carried out, I can say that all changes in the configuration were saved, when visually viewing all the objects that were changed, they retained their features and differences from the typical configuration. During operation, none of the users reported that any changes were lost.

As a result of the update, I have highlighted two small tasks for my own solution.

First. Due to the fact that the update is carried out using the "Compare, merge" mechanism, the database configuration is really updated, and updated correctly, without technical risks due to the consideration of control releases. However, the vendor configuration is not updated. Of course, a technically competent specialist can easily add this work, however I asked "1C-IzhTiSi" to send more full instructions to update. In accordance with it, even an inexperienced specialist can carry out the update.

Second. As a result of the update, all objects remain on support with the ability to change, which can also be an indirect disadvantage. If you need to use these services at a time, then you need to put all objects back on support. So far, I can only do this by going through all the metadata objects. Unfortunately, so far this process is performed manually, but in the future it will also be automated.

In addition to the two named tasks, one small flaw was discovered, which, in principle, does not affect the quality of the update and rarely appears. As a result of the update, the lines of the code of the original configuration and the updated one visually coincide, but spaces have been added at the end of the lines for some reason. This is a disadvantage, since it slightly increases the amount of changed code. And in case of further manual update it would be better not to have such pieces of code. In fig. 6 shows an example before the update, and fig. 7 - example after update.

It turned out, I'll save it for everyone:

2 configurations are stored inside the database: the vendor configuration (which is typical), and the main configuration (it is used when working with the database)

When updates are installed on a base with a configuration removed from support and revised, two configurations are actually updated: an update of the vendor's configuration (update of a typical configuration, without changes, to the current release), and an update of the main configuration.

A generic configuration cf file is used to update the vendor configuration. To update the main configuration, a previously prepared cf file is used (a typical configuration is taken, the changes made are made to it, and the configuration is dumped into the cf file)

The actual update process is carried out in 2 stages: updating the vendor configuration, and updating the main configuration. The sequence of the steps is not critical.

What are 2 configurations in 1 bottle for? This combination of base configurations is convenient to use to obtain a list of changes in a typical configuration. The main configuration contains the configuration with changes, the vendor configuration contains a typical configuration. With the help of the mechanism for comparing configurations built into the platform (in this case, the main and the supplier), you can get a visual idea of ​​what has been changed in the configuration in comparison with the typical one. The only condition for comfortable work when comparing is maintaining the same release versions of both configurations. This requires 2 cf files - one for the main one, the other for the vendor configuration.

Let's imagine that we have both cf files (for preparing cf with changes - separately) Let's call them, for example, "Typical_2_0_49_8.cf" and "Update_2_0_49_8.cf" Accordingly, the first file is an update for the vendor configuration, the second for the main configuration.

Let's start by updating the vendor configuration.

In the Configurator mode, go to the Configuration - Support - Update configuration menu. In the resulting dialog, select the "Select update file" radio button, and say "Next"

Everything is familiar here. Specify the file "Typical_2_0_49_8.cf", and click Finish

After all the questions have been settled, the platform will start loading the configuration for comparison. It takes some time ...

At the end of the download, we get the following window:

Here we are shown the differences between what we already have and what we are trying to download. The first column is the difference between the new configuration and the database configuration (main), the second is the difference between the current vendor configuration and the loaded configuration.

Since we only need to update the supplier's configuration, and do not touch the main one yet, remove all the checkboxes in the left column (if you remove the topmost one, all the others below will be removed on their own)

Click "Run", wait for a while ...

During the boot process, the following window may appear:

This refers to the blocking of base objects. If all the switches are set to the "Object not editable" mode, configuration changes will not be possible without first removing the configuration from support (objects on support, removed from support and edited while maintaining support is a separate topic) In most cases, setting up support rules is done as follows as shown in the picture

The result of all our manipulations will be a message

Go to the File - Save menu (the platform will save the changes made), and then go to the Configuration menu - Update the database configuration. The process will take some time and will require changes to be accepted during the reorganization.

This completes the first stage.

Updating the main configuration.

In the Configurator mode, go to the Configuration - Compare, merge with the configuration from the file menu. Immediately we get a window for choosing a file, in which we indicate our file for updating the main configuration "Update_2_0_49_8.cf" The platform immediately starts comparing configurations.

Since our file "Update_2_0_49_8.cf" contains an already updated configuration, taking into account all the changes, we now leave all the checkboxes in the left column in place.

After clicking the "Run" button, the configurations will be merged (similar to the first stage)

After completing all the update steps, open the database in Enterprise mode, and confirm the legality of receiving updates

In fact, if the configuration changes are minimal and known in advance, there is only one step that can be done — updating the vendor configuration. In this case, in the left column, you need to remove the checkboxes from those objects that have been changed in relation to the standard one. However, this technique is applicable only when you do not need to make changes to the forms and / or compare large blocks of code. The new typical configuration will be superimposed on the current one, with the exception of those objects that we de-merge.

The update method is universal, it is suitable not only for the configurations of "AccountingEnterprise", but also for the Complex, and for the ZUP, and for others ...

On this page I will describe the most common mistakes when using my program "".

The first and easiest option

The essence of the error and instructions for correcting it are indicated directly in the report. Well, for example, we specified the wrong username and password for the database, and then the report will contain the following lines:

The second and most difficult option

The error occurred on the 1c side, and the updater tells us about it directly with this line in the report:

In this case, we look at the report a little higher and look for green lines starting with symbols there.

These lines were transferred to the updater by the 1c platform itself, and it is they that need to be analyzed.

Below I have prepared a list of the most frequent mistakes from platform 1c (those in green) and ways to eliminate them:

Error "Name predefined element not unique "

2. Get the configuration file (.cf) of the base version somewhere - the one that we see in the "About" window. This is the most difficult stage and here I will not give ready-made solutions. You can pull this file from another database of this version, or you can ask your colleagues for it. I’ll say right away that it’s useless to ask for it - I cannot provide it to you.

3. Having on hand the configuration file (with the extension .cf) the version you want(the one that you have in the "About the program" window) in the base configurator, open the item:

We will specify the update file ourselves:

Click the Run button.

After the update, check the vendor configuration version again - now it should match the version in the "About" window. After that, the database will be updated by the updater without any problems.

What other options are there for problems?

Faulting Unit Name: frame.dll

(how to start or google).

1. If the updater is not installed on the 1c server itself, then you need to make sure that the PORT_NUMBER port on the SERVER_IP server is really open. You can check this with telnet commands SERVER_IP PORT_NUMBER. If the connection is made, then the port is open.
2. Next, you need to make sure that nothing on the computer from which the updater is running is blocking its connection to PORT_NUMBER on SERVER_IP. To do this, you need to temporarily disable antivirus, firewall, firewall and other similar programs (this must be done on the computer where the update is installed). If this step helps, then you need to register the appropriate exceptions in the blocking program.
3. If this does not help, then you need to register the base address in the updater not through the server name, but directly through its IP (its IP will be indicated in the SERVER_IP error message). This is to rule out a DNS problem.

The program cannot be launched because api-ms-crt-conio-l1 is missing on the computer. 1-0.dll

If everything is ok according to the requirements, then go to the properties of the shortcut through which you run the updater and go to the "Compatibility" tab. You need to remove all the jackdaws on this tab. Most likely, you mistakenly installed the compatibility of the updater with another OS - hence the problems with the platform (since when external connection the 1C platform code is loaded inside the updater process).

The updater takes a very long time to start

And in the "Agent port" field, the agent port is indicated (by default, 1540), which can be found in the properties of the 1c central server in the 1c cluster management console (how to start or google).

After the update, the "Rollup Date" field is hidden in the "Infobase Collapse" processing for the "Trade Management" configuration

In this case, the updater will be able to work with the database, because it will not attempt to connect to it.

But because of this, some operations of the updater on the base will not be automatically performed and will be unavailable.

Error: the connection was not established. the destination computer rejected the connection request

If you still need to unload in dt, do it in 1 thread, if possible with pauses between operations. Reboot the 1c server periodically for prophylaxis.

WITH the indicated error I came across users on almost all versions of the 1c server and in all cases they decided to switch to archiving by means of a DBMS.

Error: Unable to remove the established blocking of new sessions with the database

If this failed, then it is possible:

• you made a mistake in writing the login and / or password from the ITS
• you have not paid for access to ITS
• you are not registered basic version configurations on the 1C website for updates

3. Suppose that everything is ok with access to updates through the site. It remains to eliminate problems in the environment on your computer and problems with the 1C update server.

To do this, try downloading new updates to your configuration through the configurator (this is the way the updater uses in its work).

3.1 Go to the configurator of your base and select the "Configuration" - "Open configuration" menu item.

3.5 Finally, enter the username and password from the ITS ( be sure to copy them from notepad):

And try to download one of the updates that the configurator for your database will offer you.

If this fails, then it is possible:

• you have problems with the environment on your computer
• the 1C update server is temporarily not working properly (while updates via the site may continue to be downloaded as before)
• you do not have access to updates of this particular configuration (you have not paid for an ITS subscription to it; or you have a basic version that you did not register on the site)

4. Suppose the configurator has successfully downloaded the update. In this case, it is worth copying the ITS login and password from the notepad to the updater settings and check if the problem has disappeared.

Otherwise, there is some nuance on the side of the updater. In this case, I ask you to write to the support service at [email protected] and we will continue to understand in detail in your case.

DBMS error: Microsoft SQL Server Native Client 11.0: Invalid object name "SchemaStorage"

5. If the problem is in some a specific update (for example, it is not found or an error is issued when it is loaded into the database) -compress it into an archive and attach it to the letter... How to upload a large archive to the Internet is described (from point 5) using the example of 1c database.

Here ... I ask, of course, a lot of information, and it may not be so easy for novice users to collect and send it to me. But in this case, I ask you to turn to more experienced comrades to help you.

If you work hard, then I can work to help you.

An atypical 1C configuration is when: 1) the 1C configuration was written from scratch by the programmer, 2) the 1C configuration was typical, but changes were added to it, even if one props were added.

In this article, we will consider how it is necessary to correctly update 1C configurations, as well as several techniques for softly changing typical configurations, i.e. correct change, which will not affect the possibility of further updates.

In order to make any changes to the typical 1C configuration, it is necessary to unblock the change in the typical 1C configuration, and in some cases “remove it from support”.

In the very the best option updates, the 1C configuration can be updated completely automatic mode, this is possible when configuration changes are prohibited for us. Quite often, you need to include a configuration change as an adaptation is needed applied solutions according to the business requirements of the customer, we will stop at this option.

Before updating it is highly recommended to do backup databases, this can be done through the Administration / Unload infobase menu.

There are 2 update options: a) 1C update through support (call through the Configuration / Support / Update configuration dialog) and b) through Comparison, combining with the configuration from the file. It should be noted that the difference between the two is that in the first case, both the main configuration and the vendor configuration are updated, while when comparing the merge of configurations, only the main configuration is updated, the vendor configuration remains the same. Therefore, the most recommended option is to update via Update Configuration. For updating via Configuration Support, the CF or CFU supplier's delivery files are used, which can be found by searching, in the templates directory, specifying the path on the Internet, or directly specifying the path to the desired file on your hard drive.

When updating the 1C configuration without the possibility of making changes, the update after selecting the update file occurs in automatic mode, if the configuration is enabled for making changes, then after selecting the update file, the configuration comparison window will be displayed. In this dialog, we can see how the system invites us to update our atypical 1C configuration. In the lower part of the dialog box, there is a corresponding legend by object statuses: "Statuses by object matches" denote a comparison of the "Main configuration" and "New configuration", "Statuses by object history" denote a comparison of configuration objects with objects of the "Old vendor configuration".

By checking the boxes next to the objects, you can choose whether the current configuration object will change or remain old, as well as the method for changing the object. In the action menu it is possible to check the boxes for subsystems (this is useful if the configuration is supported by several vendors). Also in this menu it is possible to specify the merging priority for all objects at once, by default the system considers the supplier's configuration to be of higher priority. The filter settings allow us to specify which configuration objects we should display in order to be able to specify the merging mode in detail. There are several standard filter templates, and you can also specify filters for each pair of compared configurations. It is possible to set the "Show only twice changed properties" checkbox in the "Filter" settings;

So, the result will be a list of objects that have been changed twice during the revision of the standard configuration and in the new configuration of the supplier. If you agree with the update, then the improvements made earlier in these objects will be lost. Therefore, for each object, it is necessary to make a decision on how it will be updated. At this stage, a preliminary comparison should be performed solely in order to reduce the amount of work in the future. The assessment is not accurate, fast - "by eye". If there are more changes in the object in the new configuration of the provider, then we leave the instance of the provider object. We leave a check mark. Then you will need to transfer the changes from the working configuration. If there are more changes in the object in the working configuration, then we leave the instance of the object in the working configuration. Uncheck the box. Then you will need to migrate the changes from the vendor configuration. With modules, you can do a little differently, because it is possible to compare modules procedurally.

Those. in the event that in our 1C configuration and in the supplier's configuration are changed various procedures module, then, having correctly placed the checkboxes, we will save ourselves the trouble of manually transferring code changes. To get to this, you need to click the button in the form of a magnifying glass next to the name of the mode for combining modules:

When displaying a menu of actions on an object (for example, by pressing the right mouse button), we can call a report on the comparison of objects.

To confirm the performed 1C update, you need to select the Configuration / Update database configuration menu item.

To refuse to update 1C - you need to select the menu item Configuration / Return to the database configuration.

Several rules that simplify the future update of 1C configurations:

The basic rule for updating 1C: you need to add new objects, because when updating, new objects are not affected by the system

When changing the texts of modules, it is also advisable to add your own new procedures and functions, and call your new ones from the existing ones.

Using subscriptions to events, thanks to this, you can modify the typical mechanisms without changing the typical code

Using typical configuration functionality

Programmatic creation of form elements (In the event OnFormCreationOnServer)

Thanks!