Overview
The DVs in the Dataset module make it easier for you to communicate with external databases, enhancing data integration and accessibility.
On this page:
DBs
The customization properties available on Dataset DB enable users to customize connections to external databases.
Create A New Database DB
To create a new DB connection, follow the steps below:
- Access Datasets → DBs.
- Click the plus icon.
- Fill in the Name field and select a Provider and a Database. In addition, provide a meaningful description to make it easier to execute maintenance in the future.
- Click Ok.
Configure A Database DB
To configure a DB, follow the steps below.
- Access Datasets→ DBs.
- Double-click the property you wish to edit on the row corresponding to the channel you want to modify.
- Edit the property field.
The following table describes each available property you can configure when editing a DB:
If a column is not visible on the grid, enable it by right-clicking the grid header and selecting it from the list. |
Parameter | Description |
|---|---|
Name | Enter a name for the database configuration. The system will warn you if the name is not valid. |
Provider | Identifies the Provider technology used in the connection. |
Database | Identifies which type of dataset is used in this connection. |
Connection String | Enter the server path and instance needed to connect with the database, the selected Database Provider defines the syntax. It is a third-party component, and any additional parameter supported by the provider can usually be used. It supports third-party components and macros. You can use macros on the connection string. For the filename in an SQLite connection string, you can use <projectName>, which will be replaced by the solution's name, for example. |
Logon Name | You need to provide a valid login name for the database. |
Logon Password | You need to provide the password that corresponds to the database login. (Only accessible by Administrators) |
Server IP | It is an optional parameter. Provide an IP or DNS name for a computer to be used as a Secure Gateway. |
Description | Description for the database connection. |
Additional Connection Guides
In the documentation in can access guides presenting step-by-step how to connect to specific databases. Below, you find the existing guides:
Solution Test Databases Example
Assume you must transition the Alarm Historian configuration to a Microsoft SQL production database within your organization. During the development and testing phases of the application, you may prefer to wait to publish alarm events to that database. In other platforms, it would be necessary to manually switch connections between test and production environments or devise workarounds to handle this situation. We provide a built-in, optional feature. You can configure the Alarm Historian DB to target the production database, regardless of its current availability or intended use. Subsequently, run the solution in Test Mode, storing data in the local SQLite file <projectName>.dbAlarmHistorianTest.
When running the solution in validation mode, there is a configuration confirmed by default that can override the connection of the pre-defined DB, using testing ones instead. The following table lists the database files that can be enabled to use 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. |