Menu
homeiOS

Database storage structure (managed forms). Database storage structure (managed forms) 1c table structure

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 DBMS side, since the platform itself decides how many tables it should 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 using third-party tools or, as in my case, to integrate the database with external applications. In such a situation, it is necessary to have an idea in which fields of physical tables to look for the information we need.

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

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

Because of this, a better option would be to pass metadata object names into the function to reduce the amount of data returned. However, not all DBMS tables are associated with configuration metadata, so I left the option to view the full list.

Processing functionality

When a metadata tree element is activated, the list of tables, fields and indexes will be populated. When you double-click on the root of the tree, all tables are displayed, including service tables (not recommended, since the volume of data being searched increases).

In the tabular parts, standard search and list commands work.

Differences from existing implementations

There are several similar publications, for example, and. However, their inconvenience is the lack 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 functionality is closest to the author's publication (). In contrast, this processing contains the most complete tree metadata (exchange plans, constants, document logs, 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 parts.

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

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

P.S. Some employers, when hiring, ask 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 treatment is for you!

The structure in the programming language 1C 8.3 and 8.2 is a set of “Key” and “Value” pairs. The “Key” field has a string type, while the “Value” field can accept any data type. Typically used to store and transfer a set of parameters between procedures.

A structure in the 1C programming language can be created in two ways using the “New” construct.

First way:

Structure = new Structure;
Structure.Insert("ParameterKey1", "ParameterValues ​​No.1");
Structure.Insert("ParameterKey2", "ParameterValues ​​No.2");

Second way:

Structure = New Structure("ParameterKey1, ParameterKey2", "ParameterValues ​​No.1", "ParameterValues ​​No.2");

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

Get 267 video lessons on 1C for free:

Change

You can add or change a 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 a new key, add a unique name relative to all keys in the structure.

To delete a collection element, you need to use the “Delete” method, where you pass the key name:

Structure.Delete("KeyName");

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

Structure.Clear();

Traversing the structure

To iterate through a collection of a structure, you need to use the “For Each KeyValue From Structure Loop” construction.

For example:

For Each KeyMeaning From Structure Loop
…… //process, for example, change values
EndCycle;

In each cycle you will see that the following fields are available to us:

The data that determines the logic of the functioning of the system based on 1C:Enterprise belongs to the information base. The information base is stored 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 is essentially a database for the DBMS built into 1C:Enterprise 8.1.
*Microsoft SQL Server(client-server version of the information base). All infobase data is stored in a Microsoft SQL Server database.
* PostgreSQL(client-server version of the information base). All infobase data is stored in a PostgreSQL database.
* IBM DB2(client-server version of the information base). 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 information base have a similar format (differing in minor details). Some information about this format is included below.

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

*Config- basic configuration of the information base. 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 rewritten to Config when performing “Updating the database configuration” in the Configurator, and vice versa - when performing the operation “Configuration - Database Configuration - Return to DB Configuration” in the Configurator.
* Files contains service information, for example, about working with the configuration repository.
* Params contains infobase parameters. Among them:
=> List of information base users.
=> National information base settings.
=> Correspondence table between metadata objects and database objects (tables, fields, indexes).
=> Some other information.
*_YearOffset- date offset in the database. This table is created only when using Microsoft SQL Server.
* DBSchema contains information about the structure of the 1C:Enterprise database and defines other database objects used by this information base.

When 1C:Enterprise starts, it checks for the presence of the listed tables in the infobase and if any of them are missing, the message “the infobase has been destroyed” is displayed. The absence of all the listed tables means that the information base is empty. In the latter case, these tables will be created.

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

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

*_ConfigChangeRec- table for registering changes to configuration objects.
* _ConfigChangeRec_ExtProps- table of file names of modified external properties of configuration objects.

Listed below are the various metadata objects that each table 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 is involved in at least one exchange plan.
*Share plans
=> _Node - exchange plan table.
=> _Node _VT - tabular part of the exchange plan, created for each tabular part.
* Directories
=> _Reference - reference table.
=> _Reference _VT - tabular part of the directory - for each tabular part.
=> _ReferenceChangeRec - table for registering directory changes. Created if the directory participates in at least one exchange plan.
* Documentation
=> _Document - a table of documents for each metadata object "document".
=> _Document _VT - tabular part of the document - for each tabular part of each document.
=> _DocumentChangeRec - a table for registering changes to a metadata object of the “document” type. Created for each metadata object of type "document" if it participates in at least one exchange plan.
* Document sequences
=> _Sequence - document registration table - for each sequence.
=> _SequenceBoundary - table of sequence boundaries - for each sequence.
=> _SequenceChangeRec - table for recording sequence changes. Created for each sequence that participates in at least one exchange plan.
* Document logs.
=> _DocumentJournal - document journal table, created for each document journal.
* Transfers
=> _Enum - enumeration table - one for each enumeration.
* Plans for types of characteristics
=> _Chrc - main table of the plan of characteristics types.
=> _Chrc _VT - tabular part of the plan of characteristics types - for each tabular part.
=> _ChrcChangeRec - table for recording changes in the plan of characteristics types. Created if the characteristic type plan participates in at least one exchange plan.
* Charts of accounts
=> _Acc - main table of the chart of accounts.
=> _Acc _ExtDim - a table of subconto types of the chart of accounts, created for the chart of accounts if the maximum number of subcontos is greater than zero.
=> _Acc _VT - tabular part of the chart of accounts, created for each tabular part of the chart of accounts.
=> _AccChangeRec - table for recording changes in the chart of accounts. Created if the chart of accounts participates in at least one exchange plan.
* Plans for calculation types
=> _CalcKind - main table of the plan of calculation types.
=> _CalcKind _BaseCK is a table of basic calculation types, created for a plan of calculation types if its “Base dependence” property has a value other than “Does not depend”.
=> _CalcKind _DisplacedCK - a table of displaced calculation types, created for a calculation type plan if its "Uses validity period" flag is set.
=> _CalcKind _LeadingCK - table of leading calculation types - for each calculation type plan.
=> _CalcKindDN - an auxiliary table for the order of displacement, created if the plan of calculation types has the "Uses validity period" flag set.
=> _CalcKind _VT - tabular part of the plan of calculation types, created for each tabular part.
=> _CalcKindChangeRec - table for recording changes in the plan of calculation types. Created if the calculation type plan participates in at least one exchange plan.
* Information registers
=> _InfoReg - table of information register movements.
=> _InfoRegChangeRec - table for registering changes in the information register. Created if the information register participates in at least one exchange plan.
* Accumulation registers
=> _AccumReg - table of movements of the accumulation register.
=> _AccumRegTotals - table of accumulation register totals, if the register supports balances.
=> _AccumRegTurnovers - table of revolutions of the accumulation register, if the register supports revolutions.
=> _AccumRegChangeRec - table for recording changes in the accumulation register. Created if the accumulation register participates in at least one exchange plan.
=> _AccumRegOptions - table of settings for storing the totals of accumulation registers, one for all accumulation registers.
* Accounting registers
=> _AccntReg - table of movements in the accounting register.
=> _AccntRegED - a table of sub-account values ​​of the accounting register, created if it refers to a chart of accounts in which the maximum number of sub-accounts is greater than zero.
=> _AccTtl0 - table of account totals.
=> _AccTtl - where i is from 1 to the maximum number of subcontos. Table of account totals with the number of subconto types equal to i.
=> _AccTtlC - a table of totals of turnover between accounts, only for the accounting register supporting correspondence.
=> _AccntRegChangeRec - table for recording changes in the accounting register. Created if the accounting register participates in at least one exchange plan.
=> _AccntRegOptions - table of settings for storing totals, one for all accounting registers.
* Calculation registers
=> _CalcReg - table of calculation register movements.
=> _CalcRegActPer - a table of actual validity periods for the calculation register, created if the "Validity period" flag is set for the calculation register.
=> _CalcRegChangeRec - table for registering changes in the calculation register. Created for each settlement register participating in at least one exchange plan.
=> _CalcRegRecalc - calculation register recalculation table, created for each recalculation.
=> _CalcRegRecalcChangeRec - table for recording changes in recalculation. Created if recalculation is involved in at least one exchange plan.
* Business processes
=> _BPRoutePoint - table of business process route points for each business process.
=> _BusinessProcess - main table of the business process.
=> _BusinessProcess _VT - tabular part of the business process for each tabular part.
=> _BusinessProcessChangeRec - table for recording business process changes. Created for each business process participating in at least one exchange plan.
* Tasks
=> _Task - main task table.
=> _Task _VT - tabular part of the problem for each tabular part.
=> _TaskChangeRec - table for recording changes in tasks. Created for each metadata object of type "task" that participates in at least one exchange plan.

When using IBM DB2, table alias prefixes do not begin with an underscore, but instead begin with a letter part.

The number of these tables depends on the functionality of the configuration and can be quite large. In normal mode, 1C:Enterprise does not check their availability, as well as the integrity and consistency of the data contained in them. Therefore, it is important that the database in which the 1C:Enterprise 8.1 information base is located is protected from unauthorized access and its modification is carried out only using 1C:Enterprise tools. To check, you must use the "Administration - Testing and Correction" function built into the configurator.

It is also important that backup and recovery of the database storing the information base is performed only as a whole. For this purpose, it is recommended to use database backup tools built into the DBMS used. Backup of the file version of the infobase can be performed by copying the 1Cv8.1CD file.

The configurator has a special function: Administration - Upload infobase. With its help, you can upload to the specified file (upload file) all the data related to the infobase, and no more. The reverse function “Load infobase” allows you to load all the data from the upload file into the current infobase instead of the existing ones. These functions can also be used to backup infobase data in both file and client-server versions.