Connecting to an external data source 1s 8.3. External data sources

Release 8.2.14.533 is finally a more or less stable version of the 14th release of the platform. Finally, the opportunity presented itself to try out a wonderful opportunity - “external data sources”.

Why is this opportunity of such interest? Any person who has programmed in 1C and is quite familiar with SQL and is at least generally familiar with the architecture and principles of development of other technology platforms for business applications will tell you with firm confidence what he likes most about 1C. Of course, the query builder is the most convenient and thoughtful mechanism for writing queries for retrieving data from relational structures that I have personally ever encountered. And now 1C has given us such a wonderful opportunity to use it not only with 1C, but also with any other tables. It’s just that this “barrel of honey” has a lot of “flies in the ointment”. First things first:

1) Setting up and using - without “dancing with a tambourine” it won’t work

A) Add an external data source - it doesn’t seem complicated
b) check the “Select from list” checkbox - mandatory - this is necessary to check the functionality at the beginning and will save you from unnecessary troubles
V)
(IMG:http://pics.livejournal.com/comol/pic/0000cr1r.png)
- be sure to click "..." - the connection is ODBC. Not OLEDB as we are all used to, but one level lower

But be here VERY CAREFUL.

This is an ODBC driver - if you use the client-server version, it must be on the server. If you are developing on one system and working on another (as is usually the case), make sure there are no surprises waiting for you. A strange recommendation, but choose the oldest or most common driver if you are not particularly concerned about speed and do not intend to go beyond the capabilities of the SQL92 standard. This will give you better compatibility. For example, for SQL Server 2008, the best driver will be SQL Server Native Client 11, but I recommend choosing just SQL Server, otherwise this very native client will have to be installed either on the server or on all client machines (if using the file version), and the benefit is special for simple he won't give you any tasks.

E) Standard Server selection dialogs

G) Select the table and details... a wonderful opportunity - you can immediately rename it as you like (and the details too), and in the properties you will see the names of the fields of the data source

Z) Now you launch it, open the query designer - stupidly select all the records from the table and OPA - an error. What to do? If you have a managed interface, look at the service menu, and if a regular one...
I personally used this code:

Parameters = ExternalDataSources.DAX.GetGeneralConnectionParameters();
Parameters.AuthenticationStandard = True;
Parameters.UserName = "sa";
Parameters.Password = "pas";
Parameters.ConnectionString = "DRIVER=(SQL Server);SERVER=servet;UID=sa;PWD=;DATABASE=database";
Parameters.DBMS = "MSSQLServer";

ExternalDataSources.DAX.SetCommonConnectionParameters(Parameters);
ExternalDataSources.DAX.SetUserConnectionParameters(UserName(), Parameters);
ExternalDataSources.DAX.SetSessionConnectionParameters(Parameters);

ExternalDataSources.DAX.SetConnection();

Some pieces may not be necessary, but it works. You need to run the code ONCE. After which it will be normal to connect... mysticism of course - why this was necessary is not clear...

2) Read-only data sources
Yes, miracles don’t happen... but sometimes you want it that way....

3) THEY CANNOT BE USED TOGETHER WITH INTERNAL DATA SOURCES
Personally, this fact killed me on the spot.

How can this be so... what we were waiting for and already imagined and licked our lips about how we will now combine our data with 1C in one request, collapse it - group it, insert it into the report, but that’s not the case...

But of course this doesn’t stop experienced people... what thought came to mind? That's right - temporary tables:

4) THEY CANNOT BE USED TOGETHER WITH TEMPORARY TABLES

But this no longer looks like technological difficulties, but looks a lot like what they want us to do “so that life doesn’t seem like paradise” (IMG:).

5) Can only be used in ACS connections

For those who don’t know, this is in the ACS on the “Data Set Links” tab. Do you use them often? Comfortable? Apparently they want to force us to use them more often. Only there is a column “Communication condition” and “Communication parameter”. I haven’t found an example of their use in any standard configuration, and somehow everything is not transparent in the documentation and in Khrustaleva’s work either. Can anyone explain to me how the "connection condition" works. If you write Source Attributes = Receiver Attributes there, it does not work. Of course, the condition can be written in the “Expression” field - in most cases this is enough... but somehow it doesn’t work out very easily.

In total, this problem was previously solved somewhere like this:

Function InitializeDataSource()

DateStart = SettingsComposer.Settings.DataParameters.Items.Value;
DataCon = SettingsBuilder.Settings.DataParameters.Items.Value;
If DataCon > "20100101" Then
DataCon = "20100101";
endIf;

CN = New QualifiersNumbers(15,2);
KS = NewStringQualifiers(255);

ArrayNumber = New Array();
ArrayNumber.Add(Type("Number"));

ArrayString = New Array();
ArrayString.Add(Type("String"));

ArrayData = New Array();
ArrayDate.Add(Type("Date"));

//We will fill in the accounting cost in the table
TypeNumber = New DescriptionTypes(ArrayNumber, CN);
TypeString = New TypeDescription(ArrayString, KS);
TypeDate = New TypeDescription(ArrayDate);

//table for loading data from SQL
TZ = New ValueTable();
TK.Columns.Add("NomenclatureCode", TypeString);
TK.Columns.Add("Qnty", TypeNumber);
TK.Columns.Add("Period", DateType);

TK.Indices.Add("Period");

//Connect to SQL
Connection String = "Provider=SQLOLEDB.1;Persist Security Info=True;User ID=sa;Pwd=;Data Source=;Use Procedure for Prepare=1;Auto Translate=True;Packet Size=4096;Workstation ID=;Use Encryption for Data=False;Tag with column collation when possible=False;Initial Catalog=Reports";
Connection = New COMObject("ADODB.Connection");
Command = New COMObject("ADODB.Command");
RecordSet = New COMObject("ADODB.RecordSet");
Date = "";
Attempt
Connection.Open(AbbrLP(ConnectionString));
Command.ActiveConnection = Connection;
Command.CommandText = "Select * from PH where period >= "" + String(Format(DateStart, "DF=yyyyMMdd")) + "" and period RecordSet = Command.Execute();
RecordSet.MoveFirst();
Exception
Return of technical specifications;
EndAttempt;

While RecordSet.EOF = False Loop
Line = TZ.Add();
Row.NomenclatureCode = RecordSet.Fields(RecordSet.Fields.Item(1).Name).Value;
Row.Qnty = RecordSet.Fields(RecordSet.Fields.Item(12).Name).Value;
Row.Period = RecordSet.Fields(RecordSet.Fields.Item(13).Name).Value;
RecordSet.MoveNext();
EndCycle;

Request = New Request();
VrTable = New TemporaryTableManager();
Query.SetParameter("vrDataTable", TK);
Query.SetParameter("Start Date", Start Date);
Request.SetParameter("DataCon", DateCon);
Query.Text = "SELECT
| vrDataTable.NomenclatureCode,
| vrDataTable.Qnty,
| vrDataTable.Period
|Place DataTable
|FROM
| &vDataTable AS vrDataTable
|WHERE
| vrDataTable.Period >= &DateStart
| And vrDataTable.Period Query.Execute();
TZ = Undefined;

Request = New Request;
Query.TemporaryTableManager = VrTable;
Query.Text = "Here is a query involving a variable table";

Result = Query.Run();
Return Result;

EndFunction

ExternalSet = InitializeDataSource();
DataSet = new Structure();
DataSet.Insert("SQL Table", ExternalSet);
TypicalReports.GenerateTypicalReport(ThisObject, Result, Decryption Data, OutputToReportForm, DataSet);

Actually, there are not many lines of code and they are quite standard... in this case, you can use the full functionality of the query designer, and give only the DATA COMPOSITION function to the ACS

But it certainly doesn’t look as nice... and every time you need to write code to upload values into a table and check whether you made a mistake in the name of the details... and what we were given in 1C looks somehow half-hearted. I haven't decided yet which is more convenient to use. You decide, and write about your decisions and what prompted you to them.

[you must register to view the link]

1) Setup and use- without “dancing with a tambourine” it won’t work
a) Add an external data source - it doesn’t seem complicated
b) check the “Select from list” checkbox - mandatory - this is necessary to check the functionality at the beginning and will save you from unnecessary troubles
c) - be sure to click "..." - the connection is ODBC. Not OLEDB as we are all used to, but one level lower

D) But here be VERY CAREFUL.

This is an ODBC driver - if you use the client-server version, it must be on the server. If you are developing on one system and working on another (as is usually the case), make sure there are no surprises waiting for you. A strange recommendation, but choose the oldest or most common driver if you are not particularly concerned about speed and do not intend to go beyond the capabilities of the SQL92 standard. This will give you better compatibility. For example, for SQL Server 2008, the best driver will be SQL Server Native Client 11, but I recommend choosing just SQL Server, otherwise this very native client will have to be installed either on the server or on all client machines (if using the file version), and the benefit is special for simple he won't give you any tasks.
e) Standard Server selection dialogs

and DB

f) I recommend answering “yes” to the question about saving the password, otherwise you won’t be able to start this thing.
g) Select the table and details... a wonderful opportunity - you can immediately rename it as you like (and the details too), and in the properties you will see the names of the fields of the data source

h) Now you launch it, open the query designer - stupidly select all the records from the table and OPA - an error. What to do? If you have a managed interface, look at the service menu, and if a regular one...
I personally used this code:
Code 1C v 8.x Parameters = ExternalDataSources.DAX.GetGeneralConnectionParameters();
Parameters.AuthenticationStandard = True;
Parameters.UserName = "sa";
Parameters.Password = "pas";
Parameters.ConnectionString = "DRIVER=(SQL Server);SERVER=servet;UID=sa;PWD=;DATABASE=database";
Parameters.DBMS = "MSSQLServer";

ExternalDataSources.DAX.SetConnection();
Some pieces may not be necessary, but it works.
You need to run the code ONCE. After which it will be normal to connect... mysticism of course - why this was necessary is not clear...

2) Read-only data sources- Yes, miracles don’t happen... but sometimes you want it...

3) THEY CANNOT BE USED TOGETHER WITH INTERNAL DATA SOURCES
Personally, this fact killed me on the spot.

How can this be so... what we were waiting for and already imagined and licked our lips about how we will now combine our data with 1C in one request, collapse it - group it, insert it into the report, but that’s not the case...
But of course this doesn’t stop experienced people... what thought came to mind? That's right - temporary tables:

4) THEY CANNOT BE USED TOGETHER WITH TEMPORARY TABLES

But this no longer looks like technological difficulties, but looks a lot like what they want us to do “so that life doesn’t seem like paradise.”

5) Can only be used in ACS connections
For those who don’t know, this is in the ACS on the “Data Set Links” tab. Do you use them often? Comfortable? Apparently they want to force us to use them more often. Only there is a column “Communication condition” and “Communication parameter”. I haven’t found an example of their use in any standard configuration, and somehow everything is not transparent in the documentation and in Khrustaleva’s work either. Can anyone explain to me how the "connection condition" works. If you write Source Attributes = Receiver Attributes there, it does not work. Of course, the condition can be written in the “Expression” field - in most cases this is enough... but somehow it doesn’t work out very easily.

In total, this problem was previously solved somewhere like this:
Code 1C v 8.x Function InitializeDataSource()

DateStart = SettingsComposer.Settings.DataParameters.Items.Value;
DataCon = SettingsBuilder.Settings.DataParameters.Items.Value;
If DataCon > "20100101" Then
DataCon = "20100101";
endIf;

CN = New QualifiersNumbers(15,2);
KS = NewStringQualifiers(255);

ArrayNumber = New Array();
ArrayNumber.Add(Type("Number"));

ArrayString = New Array();
ArrayString.Add(Type("String"));

ArrayData = New Array();
ArrayDate.Add(Type("Date"));

//We will fill in the accounting cost in the table
TypeNumber = New DescriptionTypes(ArrayNumber, CN);
TypeString = New TypeDescription(ArrayString, KS);
TypeDate = New TypeDescription(ArrayDate);

//table for loading data from SQL
TZ = New ValueTable();
TK.Columns.Add("NomenclatureCode", TypeString);
TK.Columns.Add("Qnty", TypeNumber);
TK.Columns.Add("Period", DateType);

TK.Indices.Add("Period");

//Connect to SQL
Connection String = "Provider=SQLOLEDB.1;Persist Security Info=True;User ID=sa;Pwd=;Data Source=;Use Procedure for Prepare=1;Auto Translate=True;Packet Size=4096;Workstation ID=;Use Encryption for Data=False;Tag with column collation when possible=False;Initial Catalog=Reports";
Connection = New COMObject("ADODB.Connection");
Command = New COMObject("ADODB.Command");
RecordSet = New COMObject("ADODB.RecordSet");
Date = "";
Attempt
Connection.Open(AbbrLP(ConnectionString));
Command.ActiveConnection = Connection;
Command.CommandText = "S_elect * from PH where period >= "" + String(Format(StartDate, "DF=yyyyMMdd")) + "" and period<= "" + Строка(Формат(ДатаКон, "ДФ=ггггММдд")) + """;
RecordSet = Command.Execute();
RecordSet.MoveFirst();
Exception
Return of technical specifications;
EndAttempt;

Request = New Request();
VrTable = New TemporaryTableManager();

Query.SetParameter("vrDataTable", TK);
Query.SetParameter("Start Date", Start Date);
Request.SetParameter("DataCon", DateCon);
Query.Text = "SELECT
| vrDataTable.NomenclatureCode,
| vrDataTable.Qnty,
| vrDataTable.Period
|Place DataTable
|FROM
| &vDataTable AS vrDataTable
|WHERE
| vrDataTable.Period >= &DateStart
| And vrDataTable.Period<= &ДатаКон";
Request.Run();
TZ = Undefined;

Request = New Request;
Query.TemporaryTableManager = VrTable;
Query.Text = "Here is a query involving a variable table";

Result = Query.Run();
Return Result;

EndFunction

Starting from version 8.3.5, the platform has implemented the ability to write data to tables of external data sources. The article discusses this functionality, which expands the existing capabilities for integrating configuration with third-party systems.

Applicability

The article discusses the 1C 8.3.5 platform. The material is also relevant for current platform releases.

Recording to external data sources in 1C:Enterprise 8

In platform 8.2.14, a new object was added to the metadata tree - external data sources. The purpose of this mechanism is to obtain data from external databases in relation to 1C.

With the release of new platform releases, external data sources have evolved, for example, it has become possible to place them in temporary tables and perform connections with regular tables.

In this article we will look at what tools a developer has to record to external data sources.

All actions were performed on the Microsoft SQL Server 2008 R2 DBMS.

Platform 8.3.4 introduced the ability to use functions described in external data sources.

This feature allows you to run stored procedures on the SQL Server side, and with their help access data from external sources, including writing.

Let's look at an example. Using SQL Management Studio, let's create a new database named kursy_test. All further experiments will be performed on it.

In this database we will create a table nomenklatura, for this we will write a script with the following content:

USE [kursy_test]
GO
CREATE TABLE [dbo]. [nomenclatura](
[id] [int] NOT NULL,
[ description ] [ nvarchar ](150) NOT NULL,
[price] [numeric](15, 2) NULL,
CONSTRAINT [ PK_id ] PRIMARY KEY ([ id ])
GO

As a result of execution, a table with the following structure will be created:

Now we need to create two stored procedures, with the help of which data modification will be performed.

Let's call the first procedure insert_nomenklatura. It will be designed to add a new row to the table. The script to create it will look like this:

USE [kursy_test]
GO
CREATE PROCEDURE insert_nomenklatura
@id int
@description nvarchar(150),
@price numeric (15, 2)
AS
BEGIN
INSERT INTO [kursy_test].dbo. [nomenklatura] ([ id ], [ description ],[ price ])
VALUES (@id, @description, @price)
END
GO

The second procedure, named update_nomenklatura, will update an existing record in the table. To create it, the following script was launched:

In Object Browser, the created table and two stored procedures look like this:

We have completed all the preparatory steps on the Microsoft SQL Server side, now we go to the 1C:Enterprise 8 configurator.

Create a new external data source named Nomenklatura. When creating a new table in this data source, we specify the following parameters for connecting to the data source:

We specify the following connection string:

Driver = (SQL Server) ; Server =(local); Database = kursy_test ; User Id = sa ; Password =;

If the sa user has a password, it must be specified in the Password parameter of the connection line.

If all connection parameters are specified correctly, when you click OK, a window will open containing the tables available in the data source:

We tick the table fields that interest us. When the button is pressed Ready the dbo_nomenklatura table will be created in the external data source Nomenklatura:

Now we switch to the “Functions” tab of our data source.

Using a similar wizard, we add two stored procedures:

We get the following appearance of the “Functions” tab:

Now let's program the user interface to work with an external data source.

In the list form on the command panel, we will place the “Add” button with the following handler:

&OnClient
Procedure Add()
Alert = New DescriptionAlerts(“OpenTableComplete”, ThisObject );
OpenForm (
“ExternalDataSource.Nomenklatura.Table.dbo_nomenklatura.ObjectForm”, , , , , ,
Alert, FormWindowOpenMode.LockEntireInterface);
End of Procedure

&OnClient
Procedure Save (Command)
SaveOnServer();
End of Procedure &On Server
Procedure SaveOnServer()
If Object.Link.Empty() Then
ExternalDataSources.Nomenklatura.dbo_insert_nomenklatura
Otherwise
ExternalDataSources.Nomenklatura.dbo_update_nomenklatura
(Object.id, Object.description, Object.price);
EndIf ;
End of Procedure

In Enterprise mode, the list form looks like this:

The shape of the object is shown below:

To enlarge, click on the image.

Thus, using stored procedures, we implemented recording to external data sources.

In platform 8.3.5, a new feature has appeared - writing to external data sources directly, bypassing the stored procedure mechanism discussed above.

Data can be edited either programmatically or interactively. And for our example there is no need to resort to configuration.

In the command panels and in the “More” menu you can see standard buttons such as “Create”, “Copy”, “Edit”, etc.

To enlarge, click on the image.

And the “Save” and “Save and Close” buttons appeared in the object form:

As you can see, now working with external sources is similar to working with reference books, documents, etc.

Let's look at what changes were made at the metadata level to make it possible to write to external data sources.

A new property has been added to the data table Only reading(type – boolean).

If this property is set to True, writing data to this table using platform tools is impossible.

The data table field now has the following properties:

Only reading(type – boolean) – is it possible to change the data in this field;
AllowNull(type – boolean) – whether it is possible to store a NULL value in this field.

Property Only reading should be set to True for database fields with automatic changes, automatically generated key fields, calculated fields, etc.

You can add, change and delete data in external sources using the built-in language.

To do this, objects ExternalDataSourceTableRecordSet And ExternalDataSourceTableObject new methods were implemented Write() And Delete().

Let's look at the example of programmatically adding a new record for an external data source discussed above.

&OnClient
Procedure CreateProgrammatically(Team )
CreateProgrammaticallyOnServer();
End of Procedure &On Server

Procedure CreateProgrammaticallyOnServer()
WritableObject=
ExternalDataSources.Nomenklatura.Tables.dbo_nomenklatura.CreateObject();
WriteableObject.id= 5 ;
WriteableObject.description= “Wardrobe” ;
WritableObject.price= 5000 ;
WriteableObject.Write();
End of Procedure

In the external data source table object module, you can now specify write event handlers, such as BeforeWrite(), OnWrite() etc.:

This article examined two options for writing data to external data sources - using stored procedures and using the new mechanisms of the 8.3.5 platform.

Thus, the platform now implements mechanisms for full integration with external applications.

In version 8.3.6, the functionality described above was expanded with the help of new special methods GetModifiableFields() and SetModifiableFields(). Using them, it is possible to perform a write operation in those fields of the VIEW table that are marked in the configurator as read-only. Thanks to this, it became possible to implement a scenario in which writing to individual fields of the VIEW table is possible only in cases where it is necessary in accordance with the business logic of the application.

In version 8.3.7, the mechanism was improved to determine which specific fields of the VIEW tables can contain NULL values. Up to this point, all VIEW tables could accept this value. This change is due to an increase in the speed of sorting in dynamic lists by these fields.

In version 8.3.8, it finally became possible to detect the fact that an external data source is in a transaction state. This functionality is provided by the new method ExternalDataSourceManager.TransactionActive()

In conclusion, we note that for external data sources, as shown above, data tables from the classical relational model are described. The platform uses a different paradigm for working with data, offering the developer a certain set of types of application objects (directories, documents, registers, etc.). That is why the system, when working with tables of external data sources, does not support most of the functionality that is inherent in its “native” objects. Therefore, it is recommended to refrain from developing any business logic, taking into account the use of VID tables, if this is not related to the tasks of integration with existing systems. Or, to put it simply, you should try to avoid storing data that is actively used in your application in some other table of the external system, if it is not used by this system.

In the next article we will look at the logical continuation of using the technology of external data sources in the 1C:Enterprise system.

In version 8 of the 1C program, the developers added to the functionality the ability to connect third-party databases and obtain information from them directly from the configurator, without using COM connections and OLE objects. This feature is implemented using a new object - “External Data Sources”

External data sources in 1C can be used in the same way as other tables in the system:

When creating reports and calculations using a data composition system (DCS);
To obtain links to information stored in third party sources;
To change data stored in tables;
When generating requests.

It is important to know that this mechanism is not designed to work with other 1C databases, since the 1C.Enterprise operating model itself does not imply interference with data at the level of physical tables.

Creating a new source

Adding a new external source to the program occurs in the “Configurator” mode. There is a corresponding branch in the configuration tree (Fig. 1)

You will have to work hard when creating a new source, despite the fact that the form of the new object has only four tabs:

Basic;
Data;
Functions;
Rights.

The first tab has only one interesting parameter - the lock control mode. If you don’t have any questions about blocking data in transactions or the intricacies of parallelizing information flows, you can leave this option in automatic blocking mode. However, such an approach can lead to excessive restrictions (for example, when, instead of a separate record, the program locks the entire physical table, depriving other users of the ability to work with it).

Managed locks, unlike automatic ones, use the transaction mechanism inherent in the program itself, and not in the DBMS, which allows table captures to be transferred to a much lower level.

By setting this parameter to “Automatic and Managed,” we provide the system with the ability to determine which mode to use by directly accessing a similar property for each specific table.

“Data” tab of the external source properties form

The form of the “Data” tab is shown in Fig. 2

Rice. 2

Here we can add external source tables and cubes. There are two ways to add a table:

Manually, then the form for adding a table will open in front of us (Fig. 3);

Rice. 3

Or select from the list of physical source tables (Fig. 4), in which case a special constructor opens in front of us.

Rice. 4

Let's take a closer look at the form for adding a table. The “Name” property is used to uniquely identify an object in the configuration.

The comparison of the metadata object and the final physical table occurs through the “Name in data source” property located on the “Advanced” tab (Fig. 5)

Rice. 5

Next we must determine the type of the table, or rather its objectivity. If the data stored in a structure can be uniquely identified through any one field, the table can be an object one. If the individuality of a record is determined by a set of key fields, the table must have a non-object type.

Comparing such tables with other metadata objects, the following analogy can be given:

Object tables are reference books;
Non-object ones are information registers.

The set of key fields is defined in the next form parameter (“Key Fields”). This field is required; if you leave it blank, saving the configuration will fail.

As can be seen from Fig. 5, some fields and buttons of the form are not editable:

Expression in data source;
Table data type;
Presentation field;
View handlers.

They can be used only after we fill out the table fields, defining their type and assigning identifiers to them (Fig. 6)

Rice. 6

Here you should pay attention to the “Allow Null” parameter; if this checkbox is checked, it is not advisable to use such a field as a key.

Table builder

Perhaps the most important and interesting point in working with external sources is creating a connection string. Its constructor opens if you click the button with three dots next to the “Connection string” parameter.

First of all, we will be asked to decide on the driver that will be used for connection (Fig. 7)

Rice. 7

Incorrect definition of this parameter will not allow you to connect to a third-party infobase. You should also understand that not all drivers specified in the drop-down list can be used to automatically generate a connection string. If the platform generates an error (Fig. 8), then the connection string will have to be entered manually.

Fig.8

Rice. 9

The line itself is a strictly regulated construction.

Example connection string

Let's consider a third-party database created in Microsoft Access and located in the root of drive D. To connect this database, we must use the appropriate driver, but selecting it in the row constructor results in the error Fig. 8.

We'll set up the connection parameters ourselves.

Driver=(Microsoft Access Driver (*.mdb)) – this is what the first part of the line looks like. In curly braces we defined the driver.

For Excel files it will look like (Microsoft Excel Driver (*.xls)), for Excel files created in an office older than 2003, the driver line will look like (Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)).

Separating this parameter from the next one with a comma, we must enter the address of our storage (in our case DBQ=D:\Database1.mdb).

Adding these two parameters, we get Driver=(Microsoft Access Driver (*.mdb));DBQ=D:\Database1.mdb. By writing this parameter, we get access to the internal structures of this database.

For the “External Source” object, it is not enough just to create it in the configuration; it also needs to be connected in the “Enterprise” mode. This can be done from the menu “All functions”->External sources. When we first enter our table, we need to enter the same connection string in the “Enterprise” mode.