Export by history ID
The driver stores each exported history in a dedicated table with a name that corresponds to the history name in the framework. To ensure uniqueness and to make it possible to trace a history back to its source via the descriptive HISTORY_CONFIG table, the driver adds an incrementing number as a suffix to duplicate names.
Numeric writable export example

In this example:
The RdbmsNetwork maintains the ID and uses it for database indexing. The RdbmsNetwork driver does not use this value in a station.
TIMESTAMP records when the value was logged and can be localized to the exporting station or the source station. This choice is stored in the HISTORY_CONFIG table.
The VALUE column data type changes according to the type of the point exported, for example, double, float, enum, string or boolean.
VALUE can be {null}, for example, where {NaN} is recorded in the source history.
The driver does not export point facets (units) from the database.
The HISTORY_CONFIG table keeps track of the exported tables as in this example:

History_Config when using BY_HISTORY_ID exports

The data types of this example are:

The SOURCE column shows the origin of the history. A space separates the source point ORD and the route taken by the exported data to Supervisor. It is occasionally necessary to extend the length of the SOURCE column when station naming conventions make the ORDs very long. The DBA performs this using SQL or database management tools. This condition exhibits as a “Data Truncation” error in the application director output of the station.
The INTERVAL column shows the collection interval of the source history extension in milliseconds, the string prefix is “false” for Interval type histories.