What is 1c compatibility mode. Change or disable compatibility mode
22.02.2018
How to find out the version of the 1C:Enterprise technology platform, which is specified in the configuration compatibility mode parameter.
Get access to the 1C:Fresh cloud for free for 30 days!Most users who have been working with 1C:Enterprise programs for a long time can easily open a window with information about the program ("Help" > "About the program" or the "Show information about the program" button on the toolbar) and name the exact releases of the technology platform "1C:Enterprise" and the configuration used, specify the launch mode, client type, etc.
But sometimes our consultation line specialists ask the client to name the release number of the compatibility mode platform, which confuses most ordinary users. This information is not available in the standard "About" information window.
What is compatibility mode in 1C:Enterprise 8 programs
The 1C:Enterprise 8 technology platform is developing rapidly, the capabilities of the platform are constantly expanding, new mechanisms, tools and entire classes of objects are appearing. Naturally, developers do not have the physical ability to immediately rewrite the entire configuration taking into account new innovations that have appeared in the platform. To ensure simultaneous and joint operation of both old and new configuration elements, a compatibility mode is used, which makes it possible to run configurations developed in lower versions of the 1C:Enterprise platform on a new version of the platform without making changes to the configuration and restructuring data.
This allows you to migrate to a higher version of the platform gradually. New configuration items are added based on new platform capabilities, and old items continue to work from the beginning without making configuration changes. Necessary changes to old elements are made a little later, which allows you to smoothly raise the compatibility mode.
How to find out the 1C:Enterprise 8 configuration compatibility mode version
In order to find out the current release of compatibility mode, you need to launch the information base in the "Configurator" mode.
Select the menu item "Configuration" > "Open configuration".
The configuration tree will open. On the top line with the configuration name, right-click and select “Properties” from the drop-down menu.
The configuration properties window will open. We go down to the very bottom of the window to the last group of parameters “Compatibility”.
The last line "Compatibility mode" indicates the release number of the platform used in this configuration.
Attention! Important!
If you are not the developer of this configuration and do not know which platform version mechanisms are used by all configuration objects, then under no circumstances try to change the compatibility mode version! This may result in configuration failure and data loss.
If you are using a standard configuration, then when you change the compatibility mode, the configuration will be removed from support and you will lose the ability to automatically update.
This article is for reference only and is intended only so that you can independently clarify the version of compatibility mode.
If this information was useful to you, then like the article on social networks and share the link on your favorite forums.
Online Company, 2018
Compatibility mode of the 1C:Enterprise program, How to find out the compatibility mode version of 1C:UPP, How to find out the compatibility mode version of the 1C:Enterprise technology platform, How to find out the compatibility mode of 1C:UT, How to find out the release of the compatibility mode of the 1C:Enterprise program, How to find out the compatibility mode version 1C: Trade Management, How to find out the version of the compatibility mode in a standard 1C: Enterprise configuration, How to find out the compatibility mode of 1C: BGU, How to find out the version of the compatibility mode of 1C 8.3, How to find out the release of the compatibility mode of the 1C: Enterprise configuration, How to find out the version of the 1C compatibility mode :Accounting of a government agency, How to find out the version of the platform compatibility mode in a standard 1C:Accounting configuration, How to find out the compatibility mode of the 1C:Accounting configuration version 3.0, How to find out the compatibility mode of 1C:UPP,
Tags: How to find out the 1C release number, How to find out the 1C release, How to find out the 1C version, Help about the 1C program
A new release of the platform 8.3.11 has been released, which allows you to add and change metadata objects through the extension. Can we really now implement any improvements without removing the configuration from support? Is it worth promising a client mountains of gold without any consequences?
First of all, you need to be aware of the limitations that extensions have.
Limitation on created objects
At the moment you can create:
- Directories
- Documentation
- Information registers
- Exchange plans
You can add details to:
- Directories
- Documentation
What do we end up with? Not all types of metadata objects can be added. The most common and popular, but still not all. Additionally, new dimensions and resources cannot be added to information registers. You can only create a completely new register.
The functionality of extensions depends on the compatibility mode of the configuration to which the extension is applied.
Compatibility mode 8.3.8- you can only change the forms of objects and their modules, add your own reports and processing.
Compatibility mode 8.3.10- you can change general modules, object and manager modules, roles, use the “Before”, “After”, “Instead” directives for any modules.
Compatibility mode "Do not use"- you can use all the functionality of extensions, including adding new objects.
At the moment, the standard UT 11.3 has compatibility mode 8.3.8. In UT 11.4, the compatibility mode is 8.3.10, that is, for example, for UT, most of the extension functionality is not available, including the creation of metadata objects.
This would seem to beg the question: why not just unsupport the root, set the compatibility mode to "Do not use" and quietly use the extensions? When changing the compatibility mode, the behavior of forms and query results may change, i.e. behavior of the system as a whole. It is strongly recommended not to change the compatibility mode without first testing. But it is obvious that it seems possible to fully test (or at least partially test the documents used) an entire application solution. Therefore, you should not use this option.
When connecting an extension to a standard configuration and borrowing standard objects, the extension controls the compatibility mode of the main configuration and the types of borrowed objects and their details. If the monitored properties do not match, the extension is disabled and does not work until the cause is eliminated. That is, with a major update, there is a high probability of changing at least one of the controlled properties and causing the extension to lose functionality.
In addition, if the modifications are significant, many procedures and functions of the standard configuration are replaced, it will be necessary to carefully monitor them and, if necessary, bring them into line with the standard configuration, preserving the previously made changes.
In the above cases, you will still need the help of a programmer and, possibly, significant time for modification (but still less than when updating a configuration that has been removed from support).
conclusions
- The new release of the platform provided new opportunities for using extensions, it became possible to add metadata objects, but despite this, the functionality has certain limitations.
- The compatibility mode of the configuration to which the extension is applied greatly limits the extension's capabilities; changing the compatibility mode is not recommended.
- Large updates still require developer attention, as there is a high probability of changing controlled properties.
Cost of work and options for translations from different releases
| Translation 8.1 → 8.2.13 | Translation 8.2.13 → 8.2.16 | Translation 8.2.16 → 8.3.10 | |
|---|---|---|---|
| price, rub. * | 54,000 ₽ | 12,000 ₽ | 76,800 RUR |
A list of all changes in different versions of the platform is available at the following links:
For platform 8.2:
http://downloads.v8.1c.ru/content/Platform/8_2_19_106/1cv8upd.htm
Before starting work on transferring to 8.3 you need:
Check the controlled blocking mode. If “Automatic” is used, then when migrating to 8.3, additional costs may be required to switch to managed locking mode.
If you are using compatibility mode with 8.2.16 and higher, you need to check whether the tables have been restructured
Determine what types of clients are used (thin, thick, web client)
Determine if there are machines that run Linux
Translation of configuration 8.1 → 8.2.13
Cost of work: 54,000 rub.
Translation of configuration 8.2.13 → 8.2.16 (including restructuring)
Key changes:
The mode of storing constants and settings of accumulation registers has been changed. Each object has its own database table
The implementation of the managed locking mechanism has been reworked.
For the technological log event "TLOCK", the "Txt" property is written only in compatibility mode with version 8.2.13
The influence of the debugging mode on the speed of operation in 1C:Enterprise mode for the thin client, thick client, server and external connection has been reduced.
The execution of a query of the form “ValueType(Field1) = ValueType(Field2)” has been optimized if “Field1” and “Field2” contain values of a reference type.
For managed form fields that display attributes of a complex type, the opening of the quick selection list has been accelerated in cases where the complex type includes reference types with different quick selection settings.
For the new independent and non-periodic information register, the dimension index is clustered
Changes that require configuration changes:
When compatibility mode is disabled, the “Period” parameter of the periodic information register manager method “Get()” is required. In compatibility mode with version 8.2.13 and version 8.1, the behavior is unchanged (the method can be used without specifying a parameter, but the result is undefined).
When using the “SetValue()” and “UseFromDataSource()” methods of the “DataLockElement” object at the same time, an exception is thrown. In compatibility mode with version 8.2.13, the behavior has not changed (the value set by the “UseFromDataSource()” method takes precedence).
It is not supported to store data values that do not support serialization. In compatibility mode the behavior has not changed.
If the database is file-based, then the infobase must be converted. After the conversion begins, working with this information base with previous versions of the 1C:Enterprise 8 platform will not be possible. If development is carried out using a configuration repository, you must make a copy of the repository before converting the infobase
IMPORTANT. To get the effect of changing the compatibility mode, you need to do a restructuring through the configurator: “Administration → Testing and correction → Restructuring infobase tables.”
It is first necessary to perform restructuring on a test base and measure the execution time of this operation.
If you are using a 1C server version older than 8.2.19, for example, version 8.3, then the following errors may occur when performing restructuring:
In this case, you need to do the following:
Install a separate 1C server version 8.2.19 and deploy the database under investigation on it
Open the database in the configurator on the 1C server version 8.2.19, change the compatibility mode to “Do not use”
Restructure infobase tables
After the restructuring is completed, move the information base to the original 1C server version 8.3
The cost of transferring the configuration from 8.2.13 compatibility mode to 8.2.16 mode (non-compatible mode when using the 8.2.16, 8.2.19 platform and 8.2.16 compatibility mode when using the 8.3 platform) is 12,000 rub.
A work contract template can be downloaded.
Translation of configuration 8.2.16 → 8.3.10
The configuration translation work includes the following configuration modifications:
| 1. Eliminate property name conflicts. Changing variable names to match the new properties that appeared in 1C:Enterprise 8.3. |
| 2. Eliminate conflicting picture names. Renaming the names of pictures with names that match the names from the picture library. |
| 3. Refinement of the code when changing the properties of the fixed structure. Replacing the indication of the properties of a fixed structure with the re-creation of a fixed structure or replacing its use with a similar “Structure” type. |
| 4. Replacing the placement of non-serializable values in temporary storage with code supported in 1C:Enterprise 8.3. |
| 5. Replacing the use of calling the “Show” method for managed form details with the use of the “CurrentElement”, “CurrentPage” properties, and the “Activate” method |
| 6. Replace metadata object names longer than 80 characters with names of 80 characters or less for metadata objects |
| 7. Renaming methods and properties, according to the methodology for migrating to version 8.3. |
| 8. Improvement of mechanisms for working with selections, conditional formatting, groupings and order in dynamic lists. |
| 9. Refinement of the code for queries with the keyword “GENERAL RESULTS”, unloaded in the “Bypassing Query Result. By Grouping”, in order to preserve the previous logic of work. |
| 10. Changes in COM object class names. Replacing the names "V82.COMConnector" with "V83.COMConnector", and "V82.Application" with "V83.Application". |
| 11. Refusal in the program code of the “Start of Selection From List” event for input fields in the mode of selection from a list |
| 12. Refusal in the program code from the “ChoiceList Button” property for input fields by setting the “Dropdown List Button” property. |
| 13. Changing the code to take into account the change in the type of value returned by the global context method “SafeMode()” |
| 14. Changing the code to take into account a change in the result of a query for constants (when accessing the “Value” field of the constant table, if the constant stores a value of the type “Value Storage”, “UniqueIdentifier” or “External DataSourceTableReference”. |
| 15. Replacing the “MainRole” configuration property with “MainRoles” |
| 16. Refusal of the “User” and “Password” properties for the “InternetProxy” object and replacement with the “Set()”, “User()”, “Password()” methods. |
| 17. Improvement of the code to support the “Show in list” command, according to the method of transition to version 8.3. |
| 18. Refinement of the code to maintain the previous logic of system operation when the return value of the SystemInformation.OSVersion property has changed, |
| 19. Refinement of the code to maintain the previous logic of the system when refusing to use the system enumeration OptionOpenWindow, which is no longer available in version 8.3. |
| 20. Refinement of the code taking into account the refusal to use modal windows. |
| 21. Improvement of the code to support the web client, namely, refusal of server calls and opening windows in “Before Closing”, refusal of server calls in “When Closing”. |
| 22. Improvement of the code to make it possible to correctly use the RoleAvailable() function when passing the function as a parameter to a missing role. |
| 23. For a managed application: starting from version 8.3.8 in event handlers of a managed application BeforeSystemShutdown, WhenSystemShutdown, as well as in event handlers of a managed form that is in closing mode, BeforeClosing, WhenClosing, It is forbidden to open windows and make any server calls. The configuration needs to be improved so that forms can be closed correctly - without server calls. |
| 24. Variable name conflict: you cannot use the variable name FormParameters in a form module. Therefore, it is necessary to modify all managed forms modules that use variables named FormParameters by renaming these variables. |
The price for these works is preliminary and valid for most configurations. Before starting work when concluding a contract, we check the configuration and After checking, we confirm the price and terms of work. Checking is necessary because configurations can be very different, including heavily rewritten.
Cost of work: 76,800 rub.
A work contract template can be downloaded.
The cost of transferring the configuration to compatibility mode with 8.3.10 may be increased, If:
Configuration uses managed forms
It is necessary to abandon the use of modality
It is necessary to maintain the functionality of the configuration in Linux OS
The transition is carried out in several stages, each of them is important.
1. Preparation.
Update of the current platform release. It must be at least 8.1.5 (8.0.18).
Taking a backup.
If you use the standard configuration, no further action is required. If there are changes, then testing should be carried out using the CheckConfigurationForTranslationOn82.epf processing (available on ITS) to identify possible problems. ITS also has a method for transitioning to a new platform.
2. Conversion to 8.2. Works in 8.1 compatibility mode.
When you try to open IB 8.1 under the 8.2 platform, the program issues a corresponding warning and offers to convert the database to 8.2.
After the agreement, the actual conversion occurs. On the demo version this process may only take a few minutes. It took us 8 minutes to convert the current BP database (file version).
Important! When converting, the compatibility mode with 1C:Enterprise 8.1 is automatically set. This can be viewed in the configurator, in “Properties”.
For the user, this means that so far, at this stage, he will not see any special changes, and most of the new functionality is not available to him, in particular, working in the mode of a managed application, thin or web -client. The interface remains as in 8.1. However, the administrator can already use some of the features of 8.2.
Very important! There is no need to cancel compatibility mode right away! At least on a working basis. If the configuration is not prepared for this, then oddities in the design (possibly more serious problems) may occur; in particular, during a test transition, in one case, tabular parts and pages disappeared from all forms.
What does this stage provide?. The transition allows you to speed up the operation of the system and the ability to use some new platform mechanisms.
3. Work without compatibility mode (normal mode)
Disable compatibility mode by selecting “Do not use”:
The interface and the appearance of the buttons immediately change.
Disabling Compatibility Mode may require some configuration changes, with estimates averaging 1 day.
What does this stage provide?. After disabling compatibility mode, the speed increases even more, and 8.2 features can be used.
4. Work without compatibility mode (managed mode - partial use - full transition to managed mode)
Managed mode is enabled for some users. For this purpose, a new interface is being developed and managed forms are being created.
The “Advanced” tab appears in the configurator, and on it you can select the appropriate forms (they will be generated automatically):
Regular form:
Controlled form:
Working without compatibility mode (full transition to managed mode)
All users work with the new interface (if necessary, the normal one can be retained for some of them). The transition requires refinement of metadata settings (properties, subsystems), development of managed forms, and partial processing of application objects.
A single configuration can include the functionality of both a regular application and a managed application. The same object can have both regular and controlled forms. Their joint use is possible both during the transition period and later, if solving specific problems requires functionality that is not supported by managed forms.
It is also possible that some databases run on 8.2, and some on 8.1. However, if 8.1 and 8.2 are running in parallel, it is important to remember that there is no way back, i.e. a database opened under 8.2 will never open under 8.1.
There is a problem in installing 8.1 and 8.2 on the same server - how to get around it is indicated.
There is also a feature of updating the platform - in 8.1 it was installed, then updated, i.e. One version of the platform was installed at the same time. In 8.2, platform releases are installed in different directories (each in its own, according to the number), so an unlimited number of releases can be installed on one computer.
Important! Configuration 1.6 (also 2.0) under 8.1 and 8.2 are DIFFERENT configurations, with different updates.
The transition from BP 1.6 to BP 2.0 is also not just an update, but a separate transition. There was a situation when the built-in mechanism for switching from 1.6 to 2.0 “does not see” those databases in 1.6, which have already been converted to 8.2. Thus, it seems logical to first move from 1.6 to 2.0, and then to the 8.2 platform (perhaps this has already been fixed in new releases).
CONCLUSIONS:
1. The transition to a new platform itself is less complicated, the fewer changes in the configuration relative to the standard one.
2. To migrate while maintaining compatibility mode, no major modifications are required. The bulk of the work comes when moving to managed forms: you need to implement a new command interface and forms.
3. The new version of the platform 8.2 does not have significant differences in the user experience, therefore, they do not require any additional training.
4. It is possible to gradually transfer the configuration to a managed application mode, as well as combine the functionality of a managed application mode and a regular one in one application solution. That is, the transition can be gradual, as necessary.
