Contacts

1c correspondence of sql tables and objects. Database storage structure (managed forms). Differences from existing implementations

The structure in the 1C 8.3 and 8.2 programming language is a set of "Key" and "Value" pairs. The "Key" field has a string type, "Value" can take any data type. It is usually used to store and transfer a set of parameters between procedures.

The structure in the 1C programming language can be created in two ways using the "New" construction.

First way:

Structure = New Structure;
Structure. Insert ("KeyParameter1", "Values ​​of parameter # 1");
Structure. Insert ("KeyParameter2", "Values ​​of parameter # 2");

Second way:

Structure = New Structure ("KeyParameter1, KeyParameter2", "Values ​​of parameter # 1", "Values ​​of parameter # 2");

Both methods will create the structure that can be seen in the screenshot from the debug:

Get 267 1C video tutorials for free:

The change

You can add or change the structure using the "Insert ()" method.

Structure.Insert ("KeyName", KeyValue);

If you need to change the value of the old key, enter its name. If you add new key, add a unique name relative to all structure keys.

To delete an element of the collection, you need to use the "Delete" method, where you pass the name of the key:

Structure.Remove ("KeyName");

It is also possible to clear all objects in the collection:

Structure.Clear ();

Structure traversal

To iterate over the collection of a structure, you need to use the construct "For Each Key and Value From Structure Loop".

For example:

For Each Key And Meaning Of The Structure Loop
…… // process, for example, change values
End of Cycle;

In each cycle it will be seen that the following fields are available to us:

The data that determine the logic of the functioning of the system based on 1C: Enterprise are related to the information base. Storage information base is carried out in a database in the form of a set of tables, for which 1C: Enterprise 8.1 can use one of four database management systems (DBMS):
* Built-in in 1C: Enterprise 8.1 (file version of the infobase). In this case, all infobase data is stored in a file named 1Cv8.1CD. This file has a binary format and, in fact, is a database for the DBMS built into 1C: Enterprise 8.1.
* Microsoft SQL Server (client-server version of the infobase). All infobase data is stored in the database Microsoft data SQL Server.
* PostgreSQL(client-server version of the infobase). All infobase data is stored in the database PostgreSQL data.
* IBM DB2(client-server version of the infobase). All infobase data is stored in the IBM DB2 database.

At the level of database objects (tables, fields, indexes, etc.), both the file and client-server versions of the infobase have a similar format (differing in insignificant details). Some information about this format is contained below.

The entire infobase is presented in the database as a set of tables. Among them there are several tables that are necessarily present in the presentation of any infobase:

* Config- the main configuration of the infobase. This configuration corresponds to the real data structure and is used by 1C: Enterprise 8.0 in Enterprise mode.
* ConfigSave- configuration edited by the Configurator. The configuration from ConfigSave is overwritten in Config when "Updating database configuration" is performed in the Configurator, and vice versa - when the operation "Configuration - Database configuration - Return to database configuration" is performed in the Configurator.
* Files contains service information, for example, about working with the configuration store.
* Params contains infobase parameters. Among them:
=> List of infobase users.
=> Information base national settings.
=> Correspondence table of metadata objects and database objects (tables, fields, indexes).
=> Some other information.
* _YearOffset- offset of dates in the database. This table is only created when using Microsoft SQL Server.
* DBSchema contains information about the structure of the 1C: Enterprise database and defines other database objects used by this infobase.

At the start of 1C: Enterprise checks the presence of the listed tables in the infobase, and if any of them is missing, the message "infobase destroyed" is displayed. The absence of all the listed tables means that the infobase is empty. In the latter case, these tables will be created.

The list and structure of other database tables is determined by a specific configuration, namely, the metadata objects defined in it. Each table name consists of an alphabetic prefix followed by a number. The prefix defines the purpose of the table, and the number allows you to distinguish between tables of the same purpose that refer to different metadata objects. If IBM DB2 is used as a DBMS, then the described structure has not the names of the tables, but their aliases.

If the configuration contains at least one exchange plan with the "Distributed infobase" flag set, the following tables will be created:

* _ConfigChangeRec- table for registration of changes in configuration objects.
* _ConfigChangeRec_ExtProps- table of file names of changed external properties of configuration objects.

Listed below are the various metadata objects that tables can correspond to.

* Constants
=> _Consts contains the current values ​​of all constants defined in the configuration.
=> _ConstsChangeRec - table for registering constant changes. Created if at least one constant participates in at least one exchange plan.
* Exchange plans
=> _Node - exchange plan table.
=> _Node _VT - tabular section of the exchange plan, created for each tabular section.
* References
=> _Reference - reference table.
=> _Reference _VT - tabular section of the reference book - for each tabular section.
=> _ReferenceChangeRec - table for registering changes to the directory. Created if the directory participates in at least one exchange plan.
* The documents
=> _Document - a table of documents for each metadata object "document".
=> _Document _VT - tabular section of the document - for each tabular section of each document.
=> _DocumentChangeRec - a table for registering changes to the metadata object of the "document" type. Created for each metadata object of the "document" type, if it participates in at least one exchange plan.
* Sequences of documents
=> _Sequence - document registration table - for each sequence.
=> _SequenceBoundary - a table of sequence boundaries - for each sequence.
=> _SequenceChangeRec - table of registration of sequence changes. Created for each sequence that participates in at least one exchange plan.
* Journals of documents.
=> _DocumentJournal - a document journal table is created for each document journal.
* Enumerations
=> _Enum - enumeration table - one for each enumeration.
* Plans of types of characteristics
=> _Chrc - the main table of the chart of characteristic types.
=> _Chrc _VT - tabular section of the chart of characteristic types - for each tabular section.
=> _ChrcChangeRec - a table for registering changes in the plan of characteristic types. Created if the chart of characteristic types participates in at least one exchange plan.
* Charts of accounts
=> _Acc - the main table of the chart of accounts.
=> _Acc _ExtDim - a table of types of sub-accounts of the chart of accounts, created for the chart of accounts if the maximum number of sub-accounts is greater than zero.
=> _Acc _VT - tabular section of the chart of accounts, created for each tabular section of the chart of accounts.
=> _AccChangeRec - a table for registering changes to the chart of accounts. Created if the chart of accounts participates in at least one exchange plan.
* Plans of types of calculation
=> _CalcKind - the main table of the chart of calculation types.
=> _CalcKind _BaseCK - a table of basic calculation types, created for a chart of calculation types if its "Base dependency" property has a value other than "Does not depend".
=> _CalcKind _DisplacedCK - a table of displaced calculation types, created for a chart of calculation types if the "Uses validity period" checkbox is selected for it.
=> _CalcKind _LeadingCK - table of leading calculation types - for each chart of calculation types.
=> _CalcKindDN - an auxiliary table for the preemption order, is created if the "Uses validity period" checkbox is selected for the chart of calculation types.
=> _CalcKind _VT - tabular section of the plan of calculation types, created for each tabular section.
=> _CalcKindChangeRec - a table for registering changes in the plan of calculation types. Created if the chart of calculation types participates in at least one exchange plan.
* Registers of information
=> _InfoReg - table of movements of the register of information.
=> _InfoRegChangeRec - table of registration of changes in the register of information. Created if the information register participates in at least one exchange plan.
* Accumulation registers
=> _AccumReg - table of movements of the accumulation register.
=> _AccumRegTotals - a table of totals of the accumulation register, if the register supports balances.
=> _AccumRegTurnovers - table of turnovers of the accumulation register, if the register supports turnovers.
=> _AccumRegChangeRec - a table for registering changes in the accumulation register. Created if the accumulation register participates in at least one exchange plan.
=> _AccumRegOptions - a table of settings for storing the totals of accumulation registers, one for all accumulation registers.
* Accounting registers
=> _AccntReg - table of movements of the accounting register.
=> _AccntRegED - a table of values ​​of the accounting register subconto, created if it refers to a chart of accounts, in which the maximum number of subconto is greater than zero.
=> _AccTtl0 - table of account totals.
=> _AccTtl - where i is from 1 to maximum number subconto. The table of totals for the account with the number of types of subconto equal to i.
=> _AccTtlC - a table of totals of turnovers between accounts, only for the accounting register that supports correspondence.
=> _AccntRegChangeRec - a table for registering changes in the accounting register. Created if the accounting register participates in at least one exchange plan.
=> _AccntRegOptions - a table of settings for storing totals, one for all accounting registers.
* Calculation registers
=> _CalcReg - table of movements of the calculation register.
=> _CalcRegActPer - the table of actual validity periods for the settlement register is created if the "Validity period" checkbox is set for the settlement register.
=> _CalcRegChangeRec - a table for registering changes in the calculation register. Created for each settlement register participating in at least one exchange plan.
=> _CalcRegRecalc - A calculation register recalculation table is created for each recalculation.
=> _CalcRegRecalcChangeRec - table of registration of recalculation changes. Created if the allocation participates in at least one exchange plan.
* Business processes
=> _BPRoutePoint - a table of business process route points for each business process.
=> _BusinessProcess - the main table of the business process.
=> _BusinessProcess _VT - tabular part of the business process for each tabular part.
=> _BusinessProcessChangeRec - a table for registering changes in the business process. Created for each business process participating in at least one exchange plan.
* Tasks
=> _Task - the main task table.
=> _Task _VT - tabular section of the task for each tabular section.
=> _TaskChangeRec - a table for registering changes in tasks. Created for each metadata object of the "task" type that participates in at least one exchange plan.

When using IBM DB2, table alias prefixes do not start with an underscore, but immediately begin with an alphabetic part.

The number of these tables depends on the functionality of the configuration and can be quite large. In the normal mode, 1C: Enterprise does not check their presence, as well as the integrity and consistency of the data they contain. Therefore, it is important that the database that contains the 1C: Enterprise 8.1 infobase is protected from unauthorized access and that its modification is performed only by means of 1C: Enterprise. For verification, you must use the "Administration - Test and Repair" function built into the configurator.

It is also important that the database storing the infobase is backed up and restored only in its entirety. For this purpose, it is recommended to use funds Reserve copy databases embedded in the used DBMS. The file version of the infobase can be backed up by copying the 1Cv8.1CD file.

The configurator has special function: Administration - Unload information base. It can be used to unload in specified file(dump file) all infobase-related data and none else. The reverse function "Load infobase" allows loading all data from the upload file into the current infobase instead of the existing ones. These functions can also be used to back up infobase data in both file and client-server versions.

The 1C platform is a high-level tool for working with databases. In general, the developer does not need to think about what and how is happening on the side of the DBMS, since the platform itself decides how many tables it will create and what fields will be inside them.

However, in large projects, there is a need to work with data directly, for example, to analyze information with third-party tools or, as in my case, to integrate a database with external applications... In such a situation, it is necessary to have an idea of ​​in which fields of physical tables to search for the information we need.

The built-in function is designed for just such a case. GetDatabaseStorageStructure () that returns all the required data as a table of values. Moreover, some of the details (Fields and Indexes) of this table are themselves tables of values.

On the one hand, it is convenient to have all data in one structure, but, on the other hand, additional difficulties arise with the transfer of this table to the client (the Load () method, unfortunately, does not load nested tables). In view of this, you have to run through all the rows of the table in a loop, which, with large volumes, leads to a slowdown in work.

In this regard, the best option would be to pass the names of the metadata objects to the function to reduce the amount of data returned. However, not all DBMS tables are associated with configuration metadata, so the ability to view full list I left.

Processing functionality

When an element of the metadata tree is activated, the list of tables, fields and indices is filled. When you double-click on the tree root, all tables are displayed, including service tables (not recommended, as the amount of data being searched for increases).

V tabular sections the standard search and list commands work.

Differences from existing implementations

There are several similar publications, for example, and. However, their inconvenience lies in the absence of a metadata tree, which makes navigation difficult. The search is also carried out by the names of tables and fields in the database, and not vice versa.

The closest in functionality to the author's publication (). Unlike her, given processing contains the most complete tree metadata (exchange plans, constants, document journals, etc.). Besides the data structure is presented more clearly: the list of tables of the metadata object, the list of fields and the list of indexes are displayed in separate tabular sections.

UPD-2018-01-06 (v1.3). Fixed a bug that occurred in compatibility mode 8.3.7 and higher (platform behavior changed).

UPD-2012-08-17 (v1.2). A patch has been made for the correct processing of scheduled tasks, the item for displaying plans of calculation types has been fixed, the behavior when switching the structure type in the configuration root has been fixed.

P.S. Some employers, when hiring, ask a question about the number of physical and virtual tables for registers. It would be nice to know the answers to these questions, especially since this is the 1C: Professional level. If you want to not only learn this answer, but also "feel" these tables, then this processing is for you!



Did you like the article? Share it