Data Management

Concurrency Within The Dataset Module

Utilizing DataTable Type Tags

The Dataset Module's Select methods return a .Net Data Table object. You can directly manipulate this object in the script or assign it to a tag of the Data Table type, enabling its use across different modules like clients or reports. When mapping is not employed to assign specific row column values to Tags, the returned Data Table can be directly manipulated within the script. Alternatively, by assigning the Data Table object to a Data Table type tag, you can propagate the results to other modules, allowing you to present data conveniently in data grids, pie charts, or even XY chart presentations via the Call Back GetSamples  method.

Furthermore, scripts provide methods (TK namespace) that facilitate converting between an array of template tags and data tables and vice versa or even to .NET objects. Certain graphical elements, such as DataGrids, handle the data source similarly, whether it's a Data Table type tag or the result of a Dataset.SQL. Query command or an array of Template Tags. Understanding and efficiently utilizing this aspect of the Dataset Module is pivotal for effective query result management and distribution across your project.

Server Domain Attributes In Dataset Module

It's crucial to understand that all the attributes within the Dataset Module are server domains. Consequently, when multiple tasks or clients interact with the same qualities, competition can cause confusion during execution. Consider a scenario where a client and a Task set the SQLStatement of a query simultaneously, each providing a different value. Given that these attributes are in the server domain, the last value set in the SQLStatement will be used during command execution. This rule applies even when triggering a property in the server domain, such as the Select property.

Understanding this aspect of the Dataset Module is essential for managing concurrent operations effectively, avoiding potential conflicts, and ensuring it uses the correct value.

Understanding Dataset Module Properties

The Dataset Module comprises several server domain properties, including the Async Contents, which is a .NET Data Table type property. When the user triggers the Select property, it initiates an asynchronous execution, and the tags configured in the Mapping are assigned the values from each column of the first row. Upon triggering the Next property, the Dataset Module navigates to the succeeding row and assigns the column values to the respective tags according to the Mapping configuration. The Async Contents property stores the Data Table used for this navigation process, which is updated each time a Select command is executed.

Additionally, the user can manipulate the CursorIndex property to jump to or reverse to a specific position in the row navigation, providing enhanced control over data traversal. For synchronous commands, the method returns the Data Table and simultaneously stores it in the Local Contents property. Each execution of a synchronous command overwrites the Local Contents property with its result.

It's important to note this behavior to ensure data integrity during synchronous operations. To effectively manage data operations in your project using the Dataset module, it's crucial to understand these properties and their functions.

Store & Forward Considerations

Store & Forward built-in functionality strictly applies to databases for storing Historian and Alarm data. This feature relies on specific control columns found in the schemas of Historian and Alarm, which are not present in generic databases. Access the Store & Forward section available in the Historian Archiving Process documentation.

Manage Data Traffic Volume

The WhereCondition  property, available in Datasets → Tables, and the SQLStatement property, in Datasets → Queries, define the return condition when executing a select command in the database. Consequently, the volume of returned data can vary dramatically. Depending on the executed Query, you can receive no data or the entire table if you do not use any filter condition such as WhereCondition.

The platform does not impose any limitations on the size of the returned data. However, larger tables require more memory and increase the traffic time between the TServer, Dataset module, and the final destination. For this reason, we recommend that you be mindful of these tables' scalability and ensure your hardware can support the data volume. Otherwise, your system may suffer from significant delays, affecting your operation.

Adhere To Database-Specific SQL Syntax

The SQLStatement  property, in Dataset → Query, enables the execution of a complete SQL statement. As a result, you can use SQL syntax specific to each database. For example, SQLite supports the LIMIT clause, while SQLServer uses TOP. Similarly, different separators are used for table and column names across databases. While the system attempts to normalize and use the correct separators when using WhereCondition and filters on objects like alarm objects, in SQLStatement, it's the user's responsibility to use the correct syntax.

In this section...