Section 1 Introduction to distributed multi-layer database development

Section 1 Introduction to distributed multi-layer database development
The Multi-Tier distributed Application Services Suite (Multi-Tier distributed Application server group) proposed by Delphi places the original Two-Tier data connection to the COM component on the server, the client only has the execution file and. DLL, COM components on the front-end and server, communicate with each other through the DCOM mechanism.
This layer is called Application Server or middleware. For the overall working mechanism, see:
This multi-layer Distributed working mechanism is mainly based on the following considerations:
1) reduce the maintenance workload of the client, because the foreground program is relatively simple;
The enterprise logic is encapsulated in a general middleware application server. Different customers can share the same middle layer (including the Web) without the need for each customer to implement enterprise Rules separately, this avoids the trouble of repeated development and maintenance. Because the customer program is quite thin (this is the popular concept of thin client), both development and release have become simple.
2) Easy To upgrade. When the middleware is upgraded, the customer program may not need to change;
3) distributed data processing is implemented. By distributing an application on several machines, the performance of the application can be improved, and the sensitive part can be encapsulated in the middleware, set different access permissions for different users, enhancing security.
4) Reduce the number of users who directly connect to the database and reduce costs.
In Delphi 6.0, the DataSnap technology was developed on the basis of the original MIDAS. In many details, it provides many functions not available in the original MIDAS, making it easier to use.
DataSnap mainly provides communication between the client and the middleware. It not only supports COM + technology but also TCP/IP or CORBA. They use similar interfaces and methods, and the results are automatically completed by the program, this greatly expands its application scope.
Below are several examples to illustrate the design of multi-layer databases.
I want to solve the following problems: how to establish a simple distributed system, how to use SQL, how to transmit additional information, how to provide the server Method to the customer, and how to establish a master-slave table structure. After understanding these methods, we can build our own database system with better performance.
We need to understand these instances.
You must note that in addition to applications on the front-end machine, you must re-value a file named ". DLL" on the front-end machine to the front-end machine. This file is in the WINNT \ System32 directory of the server.

Section 2 server programs
The server program is actually a COM project. It connects to the data source and then contacts the client through the interface. This COM project must be registered on the server.
First, create a blank project.

File-> New-> Other-> Multitier-> Remote Data Module (Remote Data Module)

Dialog Box: Coclass Name: Name of the COM program. The foreground searches for the COM Program (Pct121) Instancing Based on the Name: Execution Mode. Most instances use Multiple instances (Multiple instances)
Threading Model: thread mode. Apartment (unit) is recommended)

The following describes the options.
OK to generate a window in which data controls can be placed.

In Viwe-> Type Libray, we can see some features of this COM. We
You can also write down the GUID provided by the system for later use.

Add an ADOTable and set it to point to a database.
Set a DataSetProvider (on the DataAccess page) to ADOTable

This completes the program design on the server side.
Save, compile, and register (note that it is automatically registered on the local machine as long as it is run ).
Here we need to make a few instructions:
1) on the client side, data controls are generally connected to Datasource, but on the server side, the master
To connect data to interfaces, use DataSetProvider as defined in Delphi 5.0 or later.
You do not need to perform the Export (Export) operation on each control, but
This simplifies the process and maintenance. However, each DataSet in the foreground must have
The corresponding DataSetProvider.
2) several options for creating COM are described as follows:
A) Instancing:
Multiple Instance: an application can be called by Multiple foreground programs.
It is highly efficient to start and execute without consuming too many servers.
Resource and convenient management.
Single Instance: An application can only be called by one foreground program.
So when a query crashes
Other queries, however, a front-end call must be created on the server
Creates an application server's Process (Process), which occupies Resources
Many sources affect the overall server execution efficiency.
Internal: Create an In-Process COM Program (that is, the DLL file)
Because the Mult-Tier structure, the Application Server
Different from the front-end program, the two processes of the two machines
The same Process cannot be shared, so it is rarely set to Internal.
Mode.
B) Threading Model:
Apartment: each instance can process only one Request sent by the front-end at a time (please
If multiple In-Process COM programs are created at the same time
A com program will have a current process service, so the data is secure,
Of course, you must pay attention to conflicts between some shared variables.
Single: Single-threaded, cyclic operation, no multi-task issues.
Free: allows the Remote Data Module to handle multithreading issues by itself.
The user-End program must be processed in multiple threads.
Both: almost the same as Free, but the Callback of the corresponding front-end interface is connected
Continued.
If you cannot confirm whether the registration is successful after registration, you can use C: \ WINNT \ Regedit.exe to check.

Section 3 client programs

In Two-Tier mode, the Client program is directly connected to the data source of the server,
In the Multi-Tier mode, multiple clients connect to an application server, because the charge is based on
The number of clients is calculated. Therefore, the database usage cost is relatively low.
The following example only provides the most basic functions for database operations.
Method.
1) create a common project.
2) place an TDCOMConnrction control on the Datasnap page. properties:
When registering a local machine, you can directly set the following attributes:
ServerName: Application Server Registration Name (pro1.pc121)
Connected = true activated
Then you can see that the COM program on the server is activated.
For Network debugging, you need to provide the server name:
ComputerName: Server Name (automatically giving network neighbors)
Note:
The GUID value of ServerGUID is automatically given.

3) place a TClientDataSet control (on the Data Access page)
Attribute:
Name = cdsCustomer (rename)
RemoteServer = DCOMConnrction1
ProviderName: = DataSetProvider1 (the server will be activated)
Active = true (the connection will be normal after activation)

4) Place TDataSource. properties:
Dataset: Point to cdsCustomer.

The rest is like a common database design.

We can also exercise the use of the TActionList control to do a small exercise:
First, connect to the database using a common method, and display it in a table:
Add a Toolbar and four buttons. Then add Standard -- à ActionList to the list.

Right-click ActionList and choose Action List Editor.

 

An example of multi-tier databases is in "client-2. The write and exit operations cannot be found in the Standard Action. You need to edit the settings by yourself and add two buttons in ToolBar1 to write:
Procedure TForm1.ApplyUpdateExecute (Sender: TObject );
Begin
CdsCustomer. ApplyUpdates (-1 );
ShowMessage (the database has been correctly written !!);
End;
Procedure TForm1.CloseActionExecute (Sender: TObject );
Begin
Close;
End;
The Button group is decorated below, and an ImageList1 image is transferred to the corresponding image:

Attribute Image = ImageList1 of ToolBar1
ShowHint = true
Put the Hint attribute of each Button into an appropriate value.

As long as the server is correctly registered, this program is used.
Section 4 SQL query on the client
Because the TQuery control does not exist on the client, it seems that the client server mode cannot be used for SQL
Query. However, Delphi solves this problem well. In fact, as long as the client is connected
The client's TClientDataSet contains a Provider
Corresponding to all the default properties and methods of the DataSetProvider on the server.
DataSetProvider has an Options attribute.
= True. Then, the poAllowCommandText of DataSetProvider can be accepted by the front-end.
And send it to TQuery.
It can be seen that the DataSetProvider interface is used to actually transmit data.
An interface is required to build a bridge for passing SQL statements.
The SQL query method on the client is as follows:
ClientDataSet. Close;
ClientDataSet. CommandText: = SQL statement;
ClientDataSet. Open;
The following describes the method through an instance:
I. SQL server programs:
First, use the same method to create a server-side COM project. Project name: PcSQL.
Put a Query and a DataSetProvider.

PoAllowCommandText = true under the Options attribute of DataSetProvider

In fact, a server program based on SQL queries has been created.

Section 5 Client query server alias set
Before SQL query, users often need to specify which database to query.
The BDE database Alias (Alias) on the server sets data to capture the foreground program
We use an instance to solve the problem:
Return to the server first:
Create a TSession and a TdataBase on the above server (on the BDE page)

Session1 attributes:
AutoSessionName = true
SessionName = Session1_4 (it can be automatically adjusted during running)
KeepConnection = true
Active = true

DataBase1 attributes:
AliasName: alias for connecting to the database (for example, Mymdb)
DataBaseName: custom name (for example,)
SessionName: Session1_4 (SessionName value)
If you do not want to enter the password:
LoginPrompt: false

This way
The connection attribute of Query1 needs to be changed because it needs to connect to the Database through the DataBase (in the future, you can change the connection directly by changing the Database attribute on the foreground)
DataBaseName = DataBase1 DataBaseName: custom name (for example, ).
Enter a basic SQL language for SQL properties: select * from bonus
Active = true indicates that the connection can also be established.

Added attributes for TQurey.
SessionName: Session1_4

In this way, you can use the Session object to manage the data source information.
Add four labels to display the number of online users and the number of SQL queries.

To pass the value to the client and allow the client to control the server, you need to add two methods to COM:
View-> Type Library display interface window.

Right-click IPcSQL (varies depending on the Set Name)-> New->
Create two methods ):

GetDatabaseNames is used to pass the alias data. Its Interface Information is:
Return type: HRESULT
Parameters
Name type modifier
Param1 VARIANT * [out, retval]

SetDatabaseName, used to accept information from the client. The interface information must be passed in.
Three information items (Note: The SetDatabaseName in the figure is set to SetDatabaseNames by mistake. Set it to SetDatabaseName, otherwise the call name may fail ).
Return type: HRESULT
Parameters
Name type modifier
DBName BSTR [in] ---- alias uploaded
(Add)
UserName BSTR [in]
Password BSTR [in]

After Refresh Implementation, two functions are generated.

Function TPcSQL. GetDatabasenames: OleVariant;
Begin
End;
Procedure TPcSQL. SetDatabasename (const DBname, Username,
Password: WideString );
Begin
End;

Function TPcSQL. GetDatabaseNames: OleVariant;
Var
I: Integer;
DBNames: TStrings;
Begin
// Create a string array to store all database alias data of BDE.
DBNames: = TStringList. Create;
Try
// Use the Session control to obtain all database alias data of the current BDE.
Session1.GetDatabaseNames (DBNames );
/// Create a variable array and return the Result of the variable to the function.
Result: = VarArrayCreate ([0, DBNames. Count-1], varOleStr );
// Finally, specify the database alias data to the variable array.
For I: = 0 to DBNames. Count-1 do
Result: = DBNames;
Finally
// Release the constructed DBNames if an error occurs.
DBNames. Free;
End;
End;
In addition to getting the BDE database alias, the key of the above function also declares a variable number.
Group to store database alias data, so use the VarArrayCreate function to create an array of variables,
Parameter 1: Specify the array range.
Parameter 2: array data type. The data type must be
It must be set to varOleStr.
It must also be noted that the VarArrayCreate function is created in the Variants unit. Therefore, it must be declared in implementation:
Uses Variants;
Otherwise, compilation errors may occur. If necessary, unit1.
The second process is the online data provided by the client.
Procedure TPcSQL. SetDatabaseName (const DBName, UserName,
Password: WideString );
Begin
Try
// Input the database alias, name, and password from the front-end.
// Specify three data items to the TDatabase control and perform online operations.
Database1.Close;
Database1.AliasName: = DBName;
If (UserName <>) and (Password <>) then begin
Database1.Params. Values [PASSWORD]: = Password;
Database1.Params. Values [user name]: = UserName;
End;
Database1.Open;
Except
// If an error occurs online, an exception is thrown to the foreground program.
// The foreground program will use this exception to determine whether to input
// Activate the line data window.
On E: EDBEngineError do
Raise Exception. Create (Password Required );
End;
End;
Section 6 server-side customer count

In addition to the above functions, this program also adds an online user and queries user statistics
. Because the application execution mode is Multiple Instance execution mode
After a front-end is connected to IOT platform for the first time, the application server will activate the RemoteDataModule
Event program, and the OnDestroy event program will be executed after the disconnection, so the two events can be used.
Calculate the number of users connected to the server. The calculation of the number of queries is determined by the OnAfterOpen event function of TQuery.
-----------------------------------------------------------------
Form1, mainly used for display
-----------------------------------------------------------------
First, five Tlabel controls are placed on the form, four of which are placed in the Panel1 container.
The two counting labels are named ClientCount and QueryCount respectively. Property Capyion = 0
.
Note that the following program is written in unit1.
Declare two variables in private:
FQueryCount: Integer;
FClientCount: Integer;
Declare two processes in public
Procedure UpdateClientCount (Incr: Integer );
Procedure IncQueryCount;
Write process in implementation zone:
Procedure Tform1.UpdateClientCount (Incr: Integer );
Begin
FClientCount: = FClientCount + Incr;
ClientCount. Caption: = IntToStr (FClientCount );
End;
Procedure Tform1.IncQueryCount;
Begin
Inc (FQueryCount );
QueryCount. Caption: = IntToStr (FQueryCount );
End;
--------------------------------------------------------
COM Section
--------------------------------------------------------
Create the event driver in the two events OnCreate and OnDesticy in the PcSQL window:

Procedure TPcSQL. RemoteDataModuleCreate (Sender: TObject );
Begin
End;
Procedure TPcSQL. RemoteDataModuleDestroy (Sender: TObject );
Begin
End;

Procedure TPcSQ. RemoteDataModuleCreate (Sender: TObject );
Begin
// Add a front-end plug-in (call the program on Form1)
Form1.UpdateClientCount (1 );
End;
Procedure TPcSQ. RemoteDataModuleDestroy (Sender: TObject );
Begin
// Reduce the number of frontend clients (call the program on Form1)
Form1.UpdateClientCount (-1 );
End;

Create an event driver in the event AfterOpen of Tqurey:
Procedure TPcSQL. Query1AfterOpen (DataSet: TDataSet );
Begin
End;

Procedure TPcSQ. AdHocQueryAfterOpen (DataSet: TDataSet );
Begin
// Open a new TQuery query (call the program on Form1)
Form1.IncQueryCount;
End;

Save, compile, and register

Ii. SQL client program
1) create a common project.
2) place an TDCOMConnrction control on the Datasnap page. properties:
When registering a local machine, you can directly set the following attributes:
ServerName: Application Server Registration Name (pro1.pc121)
Connected = true activated
Then you can see that the COM program on the server is activated.
For Network debugging, you need to provide the server name:
ComputerName: Server Name (automatically giving network neighbors)
Note:
The GUID value of ServerGUID is automatically given.

3) place a TClientDataSet control (on the Data Access page)
Attribute:
RemoteServer = DCOMConnrction1
ProviderName: = DataSetProvider1
Active = true (the connection will be normal after activation)

4) Place TDataSource. properties:
Dataset: pointing to ClientDataSet1
Place appropriate database binding controls. Place the Demo control as the SQL data input.
Procedure TForm1.Button1Click (Sender: TObject );
Begin
// Run the SQL command entered by the Memo user through IProvide
// Send the DataRequest Method to the application server.
ClientDataSet1.Close;
ClientDataSet1.CommandText: = Memo1.Lines. Text;
ClientDataSet1.Open;
End;

To directly call the server alias, you can add a ComboBox control:
The Create event of form1 can be written:
Procedure TForm1.FormCreate (Sender: TObject );
Var
I: Integer;
DBNames: OleVariant;
Begin
// Connect to the Application Server
DCOMConnection1.Connected: = True;
// Obtain all database alias data set for BDE
DBNames: = DCOMConnection1.AppServer. GetDatabaseNames;
// If there is database alias data, add it to the ComboBox control one by one
If VarIsArray (DBNames) then
For I: = 0 to VarArrayHighBound (DBNames, 1) do
ComboBox1.Items. Add (DBNames );
// Display the default database in the first one
ComboBox1.Text: = mymdb;
End;
After running, you can see all the server aliases:

In order to use this alias list to call other databases, a new Form must be added to some databases because they need to enter their passwords and usernames.
File-> New-> other-> new-form this adds a Form2
Add the corresponding password control.

Where: The CheckBox1 attribute Name = Check;
The Text attribute of the two Edit controls is a null string.

The two button events of Form2 can be written:
Procedure TForm2.Button1Click (Sender: TObject );
Begin
Check. Checked: = True;
Close;
End;
Procedure TForm2.Button2Click (Sender: TObject );
Begin
Check. Checked: = False;
Close;
End;
Then return to form1.
First, declare a function InputDialog in the private area to start Form2 that allows users to input online data.
Function InputDialog (var UserName, Password: String): Boolean;

The program that writes the function in the implementation area:
// Start the Form that allows the user to input online data
Function TForm1.InputDialog (var UserName, Password: String): Boolean;
Var ret: Boolean;
Begin
Ret: = False;
Try
Form2: = TForm2.Create (Application );
Form2.ShowModal;
UserName: = Form2.Edit1. Text;
Password: = Form2.Edit2. Text;
If Form2.Check. Checked then ret: = True
Else ret: = False;
Finally
Form2.Free;
Result: = ret;
End;
End;

Now, you can add a double-click event to combox1:

Procedure TForm1.ComboBox1DblClick (Sender: TObject );
Var
UserName, Password: string;
Begin
// When the data you selected in ComboBox is not a Null String
If ComboBox1.Text <> then
Begin
ClientDataSet1.Close;
Try
// First pass an empty UserName and Password to the Application Server
// If the background database is Paradox or dBASE, it may be okay,
// However, if it is an SQL base relational database, it will receive an exception.
// SetDatabaseNames is the COM method of the server.
DCOMConnection1.AppServer. SetDatabaseName (ComboBox1.Text ,,);
Except
// Because the background database is a relational database of SQL base, you must
// Enter UserName and Password through Form2 and put the data
// Pass the SetDatabaseName provided by the application server to the next number
// Perform database verification.
On E: Exception do
If E. Message = Password Required then
Begin
If InputDialog (UserName, Password) then
DCOMConnection1.AppServer. SetDatabaseName (ComboBox1.Text,
UserName, Password );
End else raise;
End;
End;
End;

You can use the server alias list to select a database.
Double-click the list box has actually implemented the connection. However, the window does not respond unless the database display is closed. That is to say, there are still some inconveniences in the use of this program, the most important thing is that the table name cannot be known after the database is connected. In this way, you cannot easily construct the SQL language for querying datasets.
Solve the problem below.
Now, let's use the GetTableNames method on the server to send the table name to the client.
Note: you must Add an output parameter with Add.

A new method is generated after refreshing:
Function GetTableNames: OleVariant; safecall;
Now you can write the method program:
Function TPcSQL. GetTableNames: OleVariant;
Var
I: Integer;
DBTables: TStrings;
Begin
// Create a string array to store all table names.
DBTables: = TStringList. Create;
Try
// Use the Database control to obtain the data of all current tables.
Database1.GetTableNames (DBTables, False );
/// Create a variable array and return the Result of the variable to the function.
Result: = VarArrayCreate ([0, DBTables. Count-1], varOleStr );
// Finally, specify the table name data to the variable array.
For I: = 0 to DBTables. Count-1 do
Result: = DBTables;
Finally
DBTables. Free;
End;
End;

Then save it, register it, and run it.

Check the client again:
Add a ComboBox to display the table name of the currently opened database.

In the. FormCreate event process, declare another variable:
DBTables: OleVariant;
At the end of the. FormCreate program, add:
// Display the table name
ComboBox2.Clear;
DBTables: = DCOMConnection1.AppServer. GetTableNames;
If VarIsArray (DBTables) then
For I: = 0 to VarArrayHighBound (DBTables, 1) do
ComboBox2.Items. Add (DBtables );
In order to correctly display the corresponding table name after changing the database, the double-click event of combox1 must be added with the corresponding section.

Procedure TForm1.ComboBox1DblClick (Sender: TObject );
Var
UserName, Password: string;
// The following two variable declarations are newly added.
DBTables: OleVariant;
I: integer;
Begin
// When the data you selected in ComboBox is not a Null String
If ComboBox1.Text <> then
Begin
ClientDataSet1.Close;
Try
// First pass an empty UserName and Password to the Application Server
// If the background database is Paradox or dBASE, it may be okay,
// However, if it is an SQL base relational database, it will receive an exception.
// SetDatabaseNames is the COM method of the server.
DCOMConnection1.AppServer. SetDatabaseName (ComboBox1.Text ,,);
Except
// Because the background database is a relational database of SQL base, you must
// Enter UserName and Password through Form2 and put the data
// Pass the SetDatabaseName provided by the application server to the next number
// Perform database verification.
On E: Exception do
If E. Message = Password Required then
Begin
If InputDialog (UserName, Password) then
DCOMConnection1.AppServer. SetDatabaseName (ComboBox1.Text,
UserName, Password );
End else raise;
End;
// Display the table name. This program is newly added.
ComboBox2.Clear;
DBTables: = DCOMConnection1.AppServer. GetTableNames;
If VarIsArray (DBTables) then
For I: = 0 to VarArrayHighBound (DBTables, 1) do
ComboBox2.Items. Add (DBtables );
ComboBox2.Text: = ComboBox2.items [0];
End;
End;
Add a double-click event to ComboBpx2 to add the table name to the SQL language:
Procedure TForm1.ComboBox2DblClick (Sender: TObject );
Begin
Memo1.text: = Memo1.text + combobox2.text;
End;
The results are completely different. You can easily select databases and tables:

Then combine the appropriate SQL language to open a suitable table.
Further consideration is that it is best to have field name data when combining new SQL languages, which does not need to be obtained from the server, because ClientDataSet actually plays a similar role in Ttable or Tquery at multiple layers, in terms of Database Control, there are almost the same languages, such as the movement of record pointers, acquisition and writing of field data, etc. In this way, you can also directly use these methods to manipulate the database.
Once again, we would like to remind you that ClientDataSet is a very powerful and important control that must be used in many advanced Delphi scenarios.
Of course, using ClientDataSet, It is also easy to obtain the field table of the opened database.
First, add a Combbox control Combbox3.

Modify the SQL query Button event as follows:
Procedure TForm1.Button1Click (Sender: TObject );
// Define two variables first
Var I, N: integer;
Begin
ClientDataSet1.Close;
ClientDataSet1.CommandText: = Memo1.Lines. Text;
ClientDataSet1.Open;
// This is the added program that displays the sub-segment name.
ComboBox3.Clear;
N: = ClientDataSet1.FieldCount;
For I: = 0 to N-1 do
ComboBox3.Items. Add (ClientDataSet1.Fields. FieldName );
ComboBox3.Text: = ComboBox3.items [0];
End;
In fact, the FormCreate event program also needs to add the corresponding program so that the sub-segment table is displayed as soon as the program is opened.
Procedure TForm1.FormCreate (Sender: TObject );
Var
// Add two definitions
I, N: Integer;
DBNames: OleVariant;
DBTables: OleVariant;
Begin
// Connect to the Application Server
DCOMConnection1.Connected: = True;
// Obtain all database alias data set for BDE
DBNames: = DCOMConnection1.AppServer. GetDatabaseNames;
// If there is database alias data, add it to the ComboBox control one by one
If VarIsArray (DBNames) then
For I: = 0 to VarArrayHighBound (DBNames, 1) do
ComboBox1.Items. Add (DBNames );
// Display the default database in the first one
ComboBox1.Text: = abc;
// Display the table name
DBTables: = DCOMConnection1.AppServer. GetTableNames;
If VarIsArray (DBTables) then
For I: = 0 to VarArrayHighBound (DBTables, 1) do
ComboBox2.Items. Add (DBtables );
ComboBox2.Text: = ComboBox2.items [0];
// Display the field table and add a program
ComboBox3.Clear;
N: = ClientDataSet1.FieldCount;
For I: = 0 to N-1 do
ComboBox3.Items. Add (ClientDataSet1.Fields. FieldName );
ComboBox3.Text: = ComboBox3.items [0];
End;
When necessary, you can also write the double-click event of combox3:
Procedure TForm1.ComboBox3DblClick (Sender: TObject );
Begin
Memo1.text: = Memo1.text + combobox3.text;
End;
Now let's look at the effect:

After the data is obtained, you can make the client program more convenient and universal. It depends on your imagination and the level of programming. Here is an example, I mainly want to provide ideas and rules for the client to use the methods provided by DCOM. Through such research, do you have a deeper understanding of DCOM and distributed database problems?

Section 7 One-to-multiple-Table server programs
1. Application Server
A standard Form must be provided in advance.
File-> New-> Multitier-> Remote Data Module
CoClass Name: Master2
Instacting: Multiple Instacting
Threading Model: Apartment

Add ADOTable1
ADOTable2
Datasouce1
DataSetProvider1 (in Data Access)
DataSetProvider2

Attribute:
ADOTable1 (master table)
ADOTable2 (slave table)
Connect a database with ConnectionString and TableName
To build a master-slave table, note the following figure:

DataSouce1 attribute: DataSet = ADOTab1
ADOTable2 property: MasterSource = performance1
MasterField = link field ()

TdataSetProvider1 attribute: Dataset = ADOTable1
TdataSetProvider2 property: Dataset = ADOTable2
This completes the server-side construction of the master-slave table.
Save, register, and run.

2. Client Programming
First, create a common project:

Add an TDCOMConnection, two TClientDataSet, and two TdataSource.

DCOMConnection1
Property: ComputerName = computer name (not to be written locally)
ServerName = server-side program name (COM)
Connecter = true (indicating connected)

ClientDataSet1
Property: RemoteServer = DCOMConnection1
ProviderName = DataSetProvider1
Active-= true
ClientDataSet2
Property: RemoteServer = DCOMConnection2
ProviderName = DataSetProvider2
Active-= true
Connect two TDataSource
ClientDataSet1 and
ClientDataSet2
Add two tdbgrids to connect the corresponding DataSource.

The master-slave table should have been created, but you can see that the master-slave relationship has not been established after you run it.

Solution:
Double-click ClientDataSet1 and a Form1.ClientDataSet1 window appears:

Right-click the blank area in the window and select Add Field in the shortcut menu. Then, we can see the last line: ADOTable2. It is very important to establish a master-slave connection.

OK, let it enter the Form1.ClientDataSet1 window (you can also adjust the fields displayed in the main table, but ADOTable2 cannot be small, it actually uses the slave table as a field of the main table ).

ClientDataSet2 attributes:
DataSetField = ClientDataSet1ADOTable2
Active = true

Okay, the master-slave relationship is established.

Through this study, we can find that DataSetProvider2 is redundant in the server program, and can not be set later. You only need one DataSetProvider1 to contact the client. This is the following server-side program connection diagram.

Also on the client:

Well, most of the technical problems of multi-layer distributed databases are basically solved here. As for the database to be better done, it is your own business, right?