How Do You Keep Tag History When Moving Tag Providers?

The trend opens, but the tag you moved from the local provider shows only new samples, an unexpected gap, or stale intervals. Start with the historian metadata. The display is usually asking for a new tag identity while the older samples still belong to the old identity.

Do not begin by rewriting every tagid in the sqlt_data_... tables. That can make raw values appear under the new tag while separating them from creation ranges, scan-class execution records, and provider partitions.

Read the failure before changing SQL

Run one history query that spans time on both sides of the provider move. Record three observations:

• Whether samples before the move are absent, stale, or attached to the old path.
• Whether samples after the move appear under the new path.
• Whether raw samples and calculated history produce the same result.

Use the result to choose the first database check:

Symptom	Likely cause
New samples appear, but all older samples are absent	The query resolves the new tagpath or tagid, while old data remains associated with the old historian entry.
Raw values appear after an ID rewrite, but intervals are stale or calculations differ	The rewritten values no longer align with sqlth_scinfo and sqlth_sce.
History changes at the provider boundary or across partitions	The provider change altered drivid, leaving data and sqlth_partitions associated with different provider identities.
Only part of the old time range appears	Multiple sqlth_te rows share the path but have different created and retired ranges; only one row was changed.

Changing the trend pen, rebuilding the displayed tag, or adjusting its current scan settings will not reconnect historical rows assigned to another historian identity. Start with sqlth_te.

Confirm whether the provider identity changed

Read the old and new entries in sqlth_te. Compare the tag path, tagid, created, retired, and the provider or driver association represented by drivid. Also count every metadata row for the old and new paths. The same tagpath can have several rows covering different creation and retirement periods.

If the provider did not change, a path-level repair is the simpler branch: rename the old historian path to the new path and preserve the old identity relationships. That retains scan-class information associated with the old tag.

If the tag moved from a local provider to a remote provider, take the provider-change branch. The new provider receives a different drivid. A path rename alone may reconnect tag-entry lookup while still leaving scan-class and partition metadata tied to the former provider.

Do not treat a successful short trend as proof that the migration is complete. Query across an old partition, the move boundary, and a new partition before choosing the repair.

Choose path reassignment before ID rewriting

Prefer updating the historical tagpath entries when you can preserve the old historian identity. This avoids rewriting all raw sample rows and keeps the existing scan-class association available for inspection.

Match by path rather than by one tagid. A single tag path can have multiple sqlth_te records with different created and retired values, and every applicable historical interval must remain reachable.

The following statement changes the old path to the new path and retires an open old entry immediately before the new entry begins:

UPDATE
sqlth_te old_tag
INNER JOIN sqlth_te new_tag ON (new_tag.tagpath = '<new_tagpath_here>' AND old_tag.tagpath = '<old_tagpath_here>')
SET
old_tag.tagpath = new_tag.tagpath,
old_tag.retired = COALESCE(old_tag.retired, new_tag.created - 1);

Replace both placeholders only after listing the matching records. The COALESCE matters: it retains an existing retired value and assigns new_tag.created - 1 only when the old value is null. An unconditional assignment would overwrite valid retirement boundaries.

This SQL uses joined-update syntax. Validate it against the database engine used by the historian, execute it first on a development gateway and copied database, and take a restorable database backup before touching production tables.

Test the creation and retirement ranges

The created and retired fields define when each historian entry represents the tag. A path may be correct while its time range still excludes the old samples.

If you reassign raw samples from an old tagid to a new tagid, compare the old and new created values. One conservative repair is to make the new record's created value match the old record's creation boundary. Basic retrieval can also work without that change, so let a boundary test decide rather than relying on one successful query.

1. Query a known raw sample timestamp earlier than the new entry's current created value.
2. Query another sample after that value.
3. Run the same range through the normal trend and any history calculation used by the application.
4. If raw retrieval works but processed history changes at the metadata boundary, repair the entry ranges before proceeding.

When the old entry already has a valid retired value, keep it. When it remains open, close it at new_tag.created - 1 so the old and new identity intervals do not overlap.

Check scan-class continuity next

Read the tag's scan-class association in sqlth_scinfo, then inspect the corresponding executions in sqlth_sce. Rewriting only tagid values in sqlt_data_... does not move these relationships.

sqlth_sce records scan-class execution periods defined in sqlth_scinfo. Its end_time continues to update while execution remains within 2*rate of the last execution. When that condition fails, the historian creates another execution entry, and queried data is stale across the gap.

This mechanism explains why an ID-only migration can display raw values yet produce incorrect quality, stale intervals, or calculation behavior. The sample timestamps may predate the execution records now associated with the new scan-class identity.

If the old and new tags use different scan classes, do not discard the former relationship. Determine whether the old scan information must remain associated with the old provider, move to the new provider, or exist as duplicated metadata covering separate time intervals. If duplication is required, relate each copied sqlth_scinfo and sqlth_sce record to the correct provider and period; do not copy records without checking their execution boundaries.

Reconcile provider partitions

A local-to-remote provider move changes drivid. Inspect sqlth_partitions before declaring either a path reassignment or an ID rewrite complete.

Map the old samples to their physical sqlt_data_... partitions, then compare those partitions with the provider identity recorded in sqlth_partitions. If records now claim the new tag identity while their partitions remain assigned to the old provider, the historian metadata no longer describes where that provider's data resides.

Take these readings in order:

1. Record the old and new drivid values.
2. Identify the partitions containing samples before and after the move.
3. Read the provider association for those partitions from sqlth_partitions.
4. Confirm that the tag-entry intervals, scan-class intervals, and partition intervals agree at the move boundary.

If they disagree, stop the direct SQL change. A provider move can require coordinated changes to tag entries, scan metadata, execution metadata, and partitions. Altering one layer at a time in production creates a database that may return plausible data for one range and fail for another.

Execute the repair and prove continuity

1. Stop further migration edits and capture the old path, new path, all matching sqlth_te rows, both provider identities, scan-class relationships, and partition records.
2. Create and test a restorable database backup. Restore it to a development environment; the presence of a backup file alone is not a recovery test.
3. Run baseline queries for raw history, trends, calculated history, and quality across the oldest required date, a normal historical period, the move boundary, and current time.
4. Choose the path-reassignment branch unless a tested requirement calls for changing raw tagid values.
5. Apply the path-based sqlth_te update to the copied database. Review every affected row, including existing retirement values.
6. Reconcile created and retired intervals. Do not overwrite a valid retirement value.
7. Validate sqlth_scinfo and sqlth_sce. Repair or duplicate their relationships only when the provider and time intervals require it.
8. Validate the old and new drivid associations in sqlth_partitions.
9. Repeat the baseline queries and compare sample counts, first and last timestamps, quality or stale intervals, and calculated results.
10. Apply the tested transaction to production only when every historical range returns through the normal application path. Keep the backup until retention and partition rollover have also been tested.

FAQ