Datasets Module Execution

Execution Process And Database Connections

The Dataset Module, specifically the TRunModule.exe (Dataset) process, reads all project configurations relevant to this module but does not directly interface with databases. The TServer provides database access services. The Dataset Module only uses TServer-provided services.

The execution of configurations made in Queries, Tables, and Files, which are Dataset features, runs in an independent process TRunModule.exe (Dataset). This process reads all the project configurations related to the Dataset Module. However, it does not directly execute the interface with the databases. Within TServer, there are services to access the database, and connections and calls to the database occur in TServer. The Dataset Module consumes this bank access service from the TServer.

Databases Connections

For each configured DB, only one access connection is created, meaning there's only one execution thread for each DB. If parallel execution of commands to the same database is required, you can create more than one DB pointing to the same database. The Dataset Module is a vital system component, functioning independently via TRunModule.exe (Dataset). Despite not interacting directly with databases, the Dataset Module reads project configurations and utilizes services within TServer to access databases. As a result, all database connections and calls occur in TServer.

Database Interactions

The Dataset Module provides two critical methods for executing data requests: 

• Synchronous
• Asynchronous

Understanding the differences between these methods, their default behaviors, and when to use each is crucial for optimizing performance and avoiding potential bottlenecks in your project.

Asynchronous Execution

This method is generally more performant and can help avoid potential locks. When properties in both Tables and Queries, such as the Select property, are triggered, the execution becomes Asynchronous. After the trigger, the execution usually continues. At the same time, the property is propagated from the trigger point, such as a screen or a script, to the server in parallel. It then synchronizes with the Dataset Module, which calls upon the necessary services from TServer to interface with the database. Upon TServer's return with the execution of the Select for the Dataset module, the result is updated in the properties and attributes of the module. Lastly, the mapping process is executed, updating Tags' values to the entire project.

Synchronous Execution

Certain methods have a Synchronous Execution. For example, when calling the SelectCommand method, the solution execution is paused until the Dataset Module carries out the service call to TServer, which interfaces with the database and returns the result to the Dataset Module. The Dataset Module then performs Tag mapping and returns the result, allowing the execution to resume.

Since the execution is paused, it's crucial to use synchronous calls carefully within mono-threaded code behind screens, whether WPF or HTML5. While synchronous execution can be appropriate in some instances, overuse can lead to performance issues. Mechanisms like the Script task or Action Server Request can facilitate asynchronous execution without using attributes. This is particularly useful when the result needs to be handled even after an asynchronous execution has been completed.

Client Vs. Server Tags in Mapping Results

In the Dataset Module, it's possible to utilize Tags from the client domain during Tag mapping. This capability provides additional flexibility when managing data in your project. When executing a synchronous or asynchronous command, the Dataset Module, not the TServer, carries out the tag assignment within the original domain of the call. 

If a call is initiated from a client, such as a screen or client script, the mapping operation between the received values and the tags occurs after TServer returns the result to the Dataset module. In this scenario, client domain Tags can be used in the mapping. The choice of the Tag domain is essential for controlling the scope of data availability. If you wish the data to be available project-wide, server domain Tags are the appropriate choice. However, if the data's scope should be confined to the client that initiated the call, client domain tags would be the best option.

This detailed understanding of the functionality of client and server domain tags in the Dataset Module's tag mapping process can enhance your project's data management efficiency and effectiveness. Selecting the correct tag domain based on your project's specific requirements is crucial, as it significantly impacts data accessibility and overall project performance.

In this section...