Page History

Execution Process And

Database Connections

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

The execution 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, which are Dataset features, runs in an independent process "process TRunModule.exe (Dataset)" that . This process reads all the project configurations related to this module but 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 merely Module 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 If parallel execution of commands to the same database is needed. In that case, creating required, you can create more than one DB pointing to the same database is possible. The Dataset module 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 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 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 is generally more performant and can help avoid potential locks. When properties in both Tables and Queries, such as the "the Select" property, are triggered, the execution becomes Asynchronous. After the trigger, the execution usually continues while . 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 moduleModule, 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 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 at this point until the Dataset module Module carries out the service call to TServer, which interfaces with the database and returns the result to the Dataset module Module. The Dataset module Module then performs tag Tag mapping and returns the result, allowing the execution to resume.

ItSince the execution is paused, it's essential to exercise caution when making 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 the need to use attributes, which 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 Tags from the client domain during tag Tag mapping. This capability provides additional flexibility when managing data in your project. When executing a synchronous or asynchronous command, the Dataset module Module, not the TServer, carries out the tag assignment within the original domain of the call. 

If Suppose a call is initiated from a client (e.g., such as 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 Tags can be used in the mapping. The choice of tag 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 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 fitoption.

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