Overview
The Database section in the Dataset module facilitates communication with external databases. Users create Dataset DBs within the Datasets → DBs section by configuring connection parameters. These connections enable seamless interaction with external databases, enhancing data integration and accessibility.
On this page:
DBs
Dataset DB Configuration Properties enable users to customize connections to external databases. Key fields include Name validation, Provider technology, and Database type. The flexible ConnectionString supports third-party components and macros, while secure access is managed through LogonName and LogonPassword. Users can optionally specify a Secure Gateway via ServerIP, and a Description field provides additional context.
Resources
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.
ConnectionString example for SQL Express
- Data Source: The server path and instance that will have the databases.
- Initial Catalog: The name of the database that will be used.
Project Test Databases and Example
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. |