The Dataset Module is a versatile tool designed for collecting, analyzing, and visualizing data from various sources within the platform. Supporting a wide range of database technologies, such as ADO.NET, ODBC, OleDB, and native interfaces, it offers seamless connectivity to key databases, including SQL Server, Oracle, SQLite, PostgreSQL, and more, making configuration simple and efficient.
Designed with real-time applications in mind, the module boasts several useful features such as multi-threaded concurrent connections, a built-in editor for SQLite, and an intuitive visual query builder. Additionally, it enables users to integrate real-time tags within query strings and manage files and recipes in ASCII, Unicode, or XML formats, enhancing the overall functionality and user experience.
On this page:
In order for the Dataset Module to communicate with an external database, a connection must be created with certain parameters. These connections, which are created within the Datasets → DBs section of the module, are referred to as Dataset DBs.
In the context of the Dataset Module, a Dataset Query refers not only to an SQL query string, but also to a Project object that has a logical name, an SQL query related to that logical name, and other parameters defined within the Datasets → Queries section. There are many ways to automatically map the results of a query execution with Tags.
A Dataset Table is a logical name that is created within a project to set up access to a specific table in a connected database. These tables are listed within the Datasets → Tables section of the module. The Tags in the real-time database can easily be mapped to columns in the tables to perform insert, update, or read operations.
A Dataset File is a logical name that defines parameters for reading and writing files in ASCII, Unicode, or XML formats.
The Datasets and SQL Queries module provides a powerful and flexible way to interact with databases, exchange data, and integrate this data into your projects. This module allows you to connect to various databases, execute SQL queries, and retrieve or manipulate data as required by your application.
Data exchange with the database is performed through a combination of queries and/or stored procedures. These can be executed on-demand, on a schedule, or triggered by events within your project. The module supports various database providers, including SQL Server, Oracle, and MySQL, enabling seamless integration with different database systems.
The data retrieved from the database can be utilized in various ways throughout your project. In the Displays module, you can use visualization tools like DataGrids to present query results on screens and dashboards. This allows you to create custom views of the data, making it accessible and easy to understand for your users.
In the Scripting module, you can create custom scripts that reference query results and use them to trigger specific actions, such as sending notifications, updating tags, or performing calculations. This enables you to implement complex logic based on the data from your database, making your project more dynamic and responsive to changes in the underlying data.
You can use the data retrieved from databases in the Datasets module for example to configure or update alarm conditions, triggers, and actions. This enables you to create dynamic alarm systems that respond to changes in your data, ensuring that your application stays responsive to real-world conditions.
SQL Query Support: The Dataset Module provides support for SQL queries, allowing users to easily extract, manipulate, and transform data from a variety of sources.
Integration with External Data Sources: The Dataset Module can integrate with a wide range of external data sources, including databases, CSV files, and other external sources, providing a flexible and powerful tool for data collection and analysis.
Access Types: Access Types allow users to group and organize data points based on their usage and permissions, providing a powerful tool for managing and controlling access to data within the Dataset Module.
Visual Query Editor: The Visual Query Editor provides a user-friendly interface for creating and editing SQL queries, making it easy for users to define complex queries without needing extensive SQL knowledge.
Customizable Dashboards: The Dataset Module provides the ability to create custom dashboards and visualizations based on the data collected by the module, allowing users to easily view and analyze data in real-time.
Store Procedures Execution: The Dataset Module can execute Store Procedures and return the results to the platform, allowing users to perform advanced data manipulation and analysis within the context of the platform.
Real-Time Execution: The Dataset Module supports real-time execution of SQL queries, allowing users to monitor and analyze data as it is generated in real-time.
The Datasets Data Server Service is an essential part of the Datasets Module. It is responsible for managing and providing efficient access to datasets, which are structured collections of data used in various project applications such as data analysis, reporting, and visualization. The service ensures high performance and seamless integration with other components, offering flexibility and ease of use when working with datasets.
The Processing Requests from Other Modules feature in FactoryStudio enables smooth communication between different project modules. It handles data requests and interactions, ensuring efficient data exchange and coordination among various components such as HMI/SCADA screens, scripting, and reporting tools.
The platform has pre-configured databases that store essential project information, including real-time and historical data, alarms, events, and system configurations. These databases provide a reliable and efficient foundation for data storage and retrieval, allowing users to focus on building and customizing their projects without worrying about database setup and management.
Data Source Virtualization is an advanced feature that simplifies data management across multiple data sources. It offers a unified interface for accessing, querying, and manipulating data, regardless of the underlying data storage technology, ensuring flexibility and ease of use.
FactoryStudio's Data Source Virtualization is designed to be agnostic and adhere to industry standards, allowing it to work seamlessly with various data storage technologies, such as SQL databases, OPC UA servers, or custom data sources. This approach enables centralized management of data connections and configurations, streamlining the process of integrating different data sources into your project.
Learn how to connect to data sources, create queries, and optimize performance for efficient data management.
This section provides essential guidance for setting up and customizing the Dataset Module, including:
The typical configuration workflow for the Dataset Module has the following sequence:
Dataset.Query
to identify those queries.When using SQLite databases, the Module Dataset can automatically create the Database if necessary; for other ones, the Database itself must already exist before you set your connection. Users with any Permission groups can create new connections in the Project, but only the Administrator can configure databases password logins.
To create a new Database connection:
Go to Datasets → DBs.
Click Create New. The Create New Database Connection window displays.
Enter or select information, as needed.
Click OK. The database is added as a new row in the table.
Edit the row fields to modify the required settings.
Dataset DB Configuration Properties | |
---|---|
Column | Description |
Name | Enter a name for the database configuration. The system allows you to know if the name is not valid. |
Provider | Identifies the Provider technology used in this connection |
Database | Identifies to which type of dataset is this connection |
ConnectionString | Enter the information needed to connect with the database. The syntax is defined by the Database Provider used, it is a third party component, any additional parameter supported by the provider can be used normally. You use macros on the connection string too. Example: for the filename in a SQLite connection string, use <ProjectName> that is replaced by the name of the project. |
LogonName | Enter a valid login name for the database. |
LogonPassword | Enter the password that corresponds to the database login. (Only accessible by Administrators) |
ServerIP | Optionally, an IP or DNS name for a computer to be used as a Secure Gateway. |
Description | Enter a description for the database connection. |
Please check the Connecting to SQL Server and Connecting to Excel for additional information.
There are four database connection already created in any new Project:
Datasets DB - Pre-defined database connections | |||
---|---|---|---|
DB | Database | Path Location | Usage |
Retentive | SQLite | <ProjectNameAndPath>.dbRetentive | Stores values for Retentive Tags. |
RuntimeUsers | SQLite | <ProjectNameAndPath>.dbRuntimeUsers | Stores dynamically created Users. |
AlarmHistorian | SQLite | <ProjectNameAndPath>.dbAlarmHistorian | Stores Alarm and AuditTrail records. |
TagHistorian | SQLite | <ProjectNameAndPath>.dbTagHistorian | Stores Tag Historian and Annotations. |
Any of them can be customized to any type of database.
The selection of best storage location depends on all kind of factors, from internal company procedures to the volume of data and how the data shall be used. Therefore, that is decision to each Project according to its requirements.
If needed to use another database for the pre-defined connections, execute the following steps:
Rename or Delete the previous DB. This step is necessary, as the system would not allow to create two objects with the same name.
Crate a new DB with the same name of the previous DB, with the required Database and connection strings.
Assume you need to transition the AlarmHistorian configuration to a Microsoft SQL production database within your organization.
During the development and testing phases of the application, you may prefer not to publish alarm events to that database yet.
In other platforms, it would be necessary to manually switch connections between test and production environments or devise workarounds to handle this situation.
In our framework, we provide a built-in, optional feature: configure the AlarmHistorian DB to target the production database, regardless of its current availability or intended use. Subsequently, run the project in Test Mode, storing data in the local SQLite file <projectName>.dbAlarmHistorianTest
.
When running the Project in Validation Mode, there is a configuration, which is true by default, that can override the connection of the pre-defined DB, using testing ones instead.
Those are database files that can be enabled to use when running in Validation Mode:
Database files used when running in Validation Mode | |||
---|---|---|---|
DB | Database | Path Location | Usage |
Retentive | SQLite | <ProjectNameAndPath>.dbRetentiveTest | Stores values for Retentive Tags. |
RuntimeUsers | SQLite | <ProjectNameAndPath>.dbRuntimeUsersTest | Stores dynamically created Users. |
AlarmHistorian | SQLite | <ProjectNameAndPath>.dbAlarmHistorianTest | Stores Alarm and AuditTrail records. |
TagHistorian | SQLite | <ProjectNameAndPath>.dbTagHistorianTest | Stores Tag Historian and Annotations. |
You can configure queries to perform more advanced functions with SQL statements to work with data from external databases.
To configure Dataset queries:
Dataset Query Configuration Properties | |
---|---|
Column | Description |
Name | Enter a name for the query. The system allows you to know if the name is not valid. |
DB | Select the database configuration. |
SqlStatement | Enter the query using SQL syntax. |
Mapping | Click "..." to select the tags that you want to populate with data from specific columns returned by the query. |
MappingDateTime | Select the time reference (UTC or Local). |
Description | Enter a description for the table configuration. |
With the Visual Query Editor, users can drag and drop tables, define relationships, and add filters and conditions using a simple graphical interface. Once the query is created, it can be saved and executed like any other query within the Dataset Module.
Check the Visual SQL Query Builder page for complete information.
To configure dataset tables:
Dataset Table Configuration Properties | |
---|---|
Field / Column | Description |
Name | Enter a name for the table configuration. The system lets you know if the name is not valid. |
DB | Select the database connecton. |
TableName | Select or type the table name in the Database you want to access |
WhereCondition | Specify the parameters that will filter the data using SQL syntax. E.g. " |
Access | Select the access permissions for the table. |
Mapping | Click "..." to select the tags that you want to populate with data in the first row of the table with data from specific columns. |
MappingDateTime | Select the time reference (UTC or Local). |
Description | Enter a description for the table configuration. |
To configure dataset files:
Go to Datasets → Files.
Enter the field values as needed.
Dataset File Configuration Properties | |
---|---|
Column | Description |
Name | Enter a name for the file configuration. The system allows you to know if the name is not valid. |
FileName | Enter the full path to the file. The file path can have Tag values embedded using curly brackets syntax. E.g.: When executing, the area in curly brackets is replaced by the value of the Tag. |
FileType | Select the type of file. |
Objects | Click "..." to select the tags that you want to populate with data from the file with data from specific columns. |
Description | Enter a description for the file configuration. |
XMLSchemaType | Represents the schema type of an XML file, which can be: a TagList, XML that contains a tag list with the tag name and tag value; or a TagObject, XML that contains the entire tag tree and its children. |
One of the key features of the Dataset Module is the ability to execute SQL queries and retrieve data in real-time. Here are some ways to leverage the runtime execution features of the Dataset Module:
The Dataset Module can be easily integrated with other modules within the software environment. Here are some examples of how the Dataset Module can be used in conjunction with other modules:
By leveraging these integration options, users can gain greater insight and control over their data sources within the platform. With the ability to execute SQL queries and trigger actions based on query results, the Dataset Module provides a powerful set of tools for working with data.
Monitoring Database Connections is an essential aspect of maintaining a reliable and efficient system within the platform. By keeping track of database connections, you can ensure that your data is being accessed and updated correctly. Here are some ways to monitor database connections:
1. IsStarted: This property indicates if the dataset is started, meaning it has been initialized and connected to the database. You can use it to check if the dataset is currently running.
bool isStarted = @Dataset.DB.YourDatabaseName.IsStarted; |
2. Query Execution Time: You can measure the execution time of a query by checking the time before and after executing the query.
DateTime startTime = DateTime.Now; @Dataset.Query.YourQueryName.SelectCommand(); DateTime endTime = DateTime.Now; TimeSpan executionTime = endTime - startTime; |
3. ConnectionString: You can check the connection string used for the database to ensure it is configured correctly.
string connectionString = @Dataset.DB.YourDatabaseName.ConnectionString; |
Please note that these are just examples, and you will need to replace YourDatabaseName and YourQueryName with the actual names of the database and query you are working with in the platform. |
One of the key features of the Dataset Module is the ability to display query results on screens and dashboards using visualization tools like DataGrids. Here are some steps for using DataGrids to display query results:
Users can use query results to trigger actions in custom scripts and tags. Here are some steps for using query results in scripts and tags:
Check the Using Stored Procedures page for additional information.
The Dataset namespace exposes properties and methods of the .NET objects used by the Dataset Module execution.
For more information on namespaces and objects, go to Objects and Attributes.
Dataset Module Properties examples | |||
---|---|---|---|
Property | Type | Description | Example |
CursorIndex | Integer | Represents the current position of a cursor within the result set of a query. It is an integer value that indicates the row number in the result set that the cursor points to, with the first row having an index of 0. The cursor can be used to navigate through the result set, allowing you to read, update, or delete rows of data. |
|
OpenStatusMessage | String | Provides a human-readable message describing the current state of the database connection. This can be useful for monitoring the connection status, diagnosing issues, or displaying the connection status to users in a user-friendly format. |
|
ConnectionString | String | Used to store the necessary information for establishing a connection to a database. It is a string value containing details such as server name, database name, authentication credentials, and other relevant parameters. |
|
This section describes only some commonly used properties, for the full list properties and methods, go to the Namespaces Reference.