Page History

Execution Process And Databases Connections

The Dataset module, specifically the TRunModule.exe (Dataset) process, reads all project configurations relevant to this module but does not directly interface with the databases. Database access services are provided by TServer, with the Dataset module consuming these services. The execution of the Dataset module, i.e., executions of configurations made in Queries, Tables, and Files, runs in an independent process "TRunModule.exe (Dataset)" that reads all the project configurations related to this module but 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 merely consumes this bank access service from the TServer

Databases Connections

For each configured DB, only one access connection is created for this database, meaning that there's only one execution thread for each DB. Suppose parallel execution of commands to the same database is needed. In that case, creating more than one DB pointing to the same database is possible. The Dataset module is a vital system component, functioning independently via TRunModule.exe (Dataset). It's important to understand that this module does not directly interact with the databases. However, instead, it reads project configurations related to the module and utilizes services within TServer to access databases. As a result, all database connections and calls occur in TServer.

Database Interactions: Synchronous, Asynchronous and Distributed Access

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 while the property is propagated from the trigger point (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. It then undergoes mapping treatment with tags and is made available to the entire project.

Synchronous Execution

Certain methods have a Synchronous Execution. For example, when calling the SelectCommand method, the execution is paused at this point 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.

It's essential to exercise caution when making synchronous calls 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 the need to use attributes, which 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. Suppose a call is initiated from a client (e.g., a screen or client script). In that case, 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 mapping. The choice of 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 fit.

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...