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
=>
_Node
* References
=>
_Reference
=>
_Reference
=>
_ReferenceChangeRec
* The documents
=>
_Document
=>
_Document
=>
_DocumentChangeRec
* Sequences of documents
=>
_Sequence
=>
_SequenceBoundary
=>
_SequenceChangeRec
* Journals of documents.
=>
_DocumentJournal
* Enumerations
=>
_Enum
* Plans of types of characteristics
=>
_Chrc
=>
_Chrc
=>
_ChrcChangeRec
* Charts of accounts
=>
_Acc
=>
_Acc
=>
_Acc
=>
_AccChangeRec
* Plans of types of calculation
=>
_CalcKind
=>
_CalcKind
=>
_CalcKind
=>
_CalcKind
=>
_CalcKindDN
=>
_CalcKind
=>
_CalcKindChangeRec
* Registers of information
=>
_InfoReg
=>
_InfoRegChangeRec
* Accumulation registers
=>
_AccumReg
=>
_AccumRegTotals
=>
_AccumRegTurnovers
=>
_AccumRegChangeRec
=>
_AccumRegOptions - a table of settings for storing the totals of accumulation registers, one for all accumulation registers.
* Accounting registers
=>
_AccntReg
=>
_AccntRegED
=>
_AccTtl0
=>
_AccTtl
=>
_AccTtlC
=>
_AccntRegChangeRec
=>
_AccntRegOptions - a table of settings for storing totals, one for all accounting registers.
* Calculation registers
=>
_CalcReg
=>
_CalcRegActPer
=>
_CalcRegChangeRec
=>
_CalcRegRecalc
=>
_CalcRegRecalcChangeRec
* Business processes
=>
_BPRoutePoint
=>
_BusinessProcess
=>
_BusinessProcess
=>
_BusinessProcessChangeRec
* Tasks
=>
_Task
=>
_Task
=>
_TaskChangeRec
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!