Page History

Datasets Module Execution

The Dataset module facilitates efficient database interactions by utilizing TServer services. While it doesn't directly interact with databases, it manages synchronous and asynchronous executions for optimal performance. Understand the differences between these methods by reading more on the Databases Connection And Interactions Datasets Module Execution page.

Data Management

The Dataset Module offers versatile methods for managing data and concurrency within projectssolutions, including Data Table tags and Async Contents. Understand how to avoid conflicts and optimize performance, reading more on the Data Management page.

Datasets Runtime Attributes

The   Datasets Namespace  exposes properties and methods from the .NET objects used by the Historian Module execution. You can use these properties and methods on your Displays or to create Scripts and Alarms. The Dataset Runtime Attributes page lists all options available.

Preventing SQL Injections

When calling Stored Procedures in the database, there's a significant concern about SQL injection, especially when passing parameters as plain text in SQL statements. To mitigate this, we utilize the .Net NET API, where parameters are added to a list, effectively preventing code injection. Therefore, we advise using parameters in Stored Procedure calls with the following syntax:

execute <StoredProcedureName> <@paramName1>={Tag.Tag1}, <@paramName2>="{Tag.TagStr}", <@paramName3>={Tag.OutValue} OUTPUT, ... , @RETURN_VALUE={Tag.RetValue} RETURNVALUE

This approach parameterizes Stored Procedure calls and guards against SQL injection attacks. Each parameter value is strictly interpreted as a value and not part of the SQL command, providing a critical layer of security against unauthorized database manipulation.

Network Gateway Access And Time Zone Handling

In some scenarios, specific databases might not be accessible from all computers due to network topology or security constraints. The ServerIP column can redirect database access commands to a machine with the necessary permissions, provided you install our platform on that machine. Only TWebServer would be active in such cases, handling database interaction, receiving commands, and establishing connections. This method offers a workaround for database access restricted to specific machines.

Handling Time Zones

The platform treats all Date and Time type Tags tags as UTC. Consequently, the dates written to and read from the standard database, such as historical data and alarms, are also in UTC. If it 's is necessary to read and write dates in the local timezone, account for the time difference when preparing the SQL statement or using the WhereCondition   property. Other external data tables, from third parties or the client, can use any timezone. To assist in handling these this data, you can configure the DateTimeMode DateTimeMode column with the type of timezone used in the database (UTC or Local Time), and the system will automatically convert it when reading and writing to Tagstags.

Dataset Module Performance

The Dataset moduleModule's performance depends on many factors, including database performance, network latency, and the complexity of executing SQL queries. The platform will minimize overhead and execute queries as efficiently as possible. However, ultimately, the performance of the Dataset module is tied to these external factors. It's essential to design your database schema and queries with performance in mind and consider investing in high-quality hardware and network infrastructure to ensure optimal performance.

Error Handling

Error handling in the Dataset module is straightforward. Suppose If an error occurs during the execution of a command. The , the error message will update the module's Error property (Last Status). You can monitor this property to handle errors in your application. Furthermore, suppose if an error occurs during the execution of a synchronous method. In that case, the process will return an empty Data Table , and update the Error property. Alternatively, you can call methods like SelectCommandWithStatus, where the status will be an output parameter in the method.

These are some of the key points you should keep in mind while using the Dataset module. It's a powerful tool that provides much a lot of flexibility. However, it also requires careful use and understanding of its features and limitations. Always keep best practices in mind when designing and implementing your database interactions. Feel free to seek expert advice if you need clarification on anything.

Backup

of SQLite

Databases

There are several ways to backup back up SQLite databases in a projectsolution. One simple way method is to make a copy of the database file itself, but this method may not be suitable if the database is actively being written to or is very large. Here are a few suggestions for backing up SQLite databases in your projectsolution:

• SQLite provides a built-in backup command that can be used to create a backup of a database file. The syntax for this command is as follows:

  Code Block
  sqlite3 source_database.sqlite .backup backup_file.sqlite

  This command creates a backup of the source database and stores it in a new file called

   

  backup_file.sqlite. You can then copy this file to a safe location for backup purposes.

• SQLite also provides an Online Backup API that you can use to create a backup of a database file while your application is still using it. This API provides offers several benefits over the backup command, such as the ability to perform incremental backups and monitor the progress of the backup process. Read more on in the SQLite Backup API documentation.

Regardless of your chosen method, it's crucial to store your backup files in a secure location and test them regularly to ensure that you can use them to restore your database if needed.

In this section

: