I’m working on a new application, but I was working on a old gateway. I need to Debug all things for the previous gateway. I deleted almost all configurations. But I can’t remove “Historical Tag Providers”.
This is my problem I need to remove this configuration. Is there any solution?
Historical providers are automatically created for each database connection. If you remove the database connection with the same name, the history provider will be deleted.
you can (and should) disable historical tag providers for any database connections you don’t want to store tag history to.
Personally I create a schema called historian, and use that explicitly for storing tag history.
I already delete the database conections tha I don’t need, but still don’t delete.
If the relevant historical connections have already been deleted, then it’s possible the internal database hasn’t been updated. Send an email to firstname.lastname@example.org and we’ll be able to take a look.
I have the same problem. See attached. I deleted the old MySQL database connection but the datasource history provider remains. Please can you show me how to delete it?
The easy fix is just to create a non-working database connection with the same name as the one you want to delete, and then delete that new database connection. That should automatically remove the history provider as well.
Thanks for the reply. I tried your suggestion. Unfortunately, this created a new history provider with the same name. At this point I had two history providers called “delete_me”. I then deleted the database connection of the same name and I was left with one history provider called “delete_me”.
Any other ideas?
The other avenue involves going into the internal database, which is inherently risky. If you’re not comfortable, or not willing to take the risk, then I would suggest contacting support.
If you do just want to do it, then:
- Get a gateway backup. This should always be your first step when doing any significant modification, but especially when directly affecting the internal database.
- Navigate to the “Status” section of the gateway web interface. Then add
sys.internaldb to the path in the URL bar, so you’re navigating to something like
- Run a query to find the ID of the provider record you need to delete, in the query box:
select TAGHISTORYPROVIDEREP_ID, NAME, ENABLED, TYPE, DESCRIPTION from TAGHISTORYPROVIDEREP;
- Run the appropriate delete query to remove that record.
Perfect! Easy fix. Thanks for your help.
The status/sys.internaldb looks like a (nice) undocumented feature. Are there other sys.% functions? Any way to have this database query use a different db connection?
Nothing else that’s hidden. The internal DB access point is mostly there for support; it’s a lot easier to use that than try to install SQLite binaries onto customer’s systems.
And no way to retarget it to a different connection, although recent versions of 8.0 have a bundled SQLite database connection type and driver that you could use to talk to other SQLite dbs. I would definitely not recommend trying to point it at any active Ignition system’s
config.idb file, though.
What would be the appropriate delete query? Or what might that look like?
You cut off Paul’s warning:
If you aren’t comfortable looking at the data in the the config DB and cannot construct a relevant delete query, you really need to work through support.
Thanks, but I am not worried about my local project. I have a backup of it. Just looking for some help. Appreciate your input.
On a serious note, if you can’t come up with the delete statement on your own you should call support. Which is what was stated to you above.
So sorry. Did not mean to “bother” you all.
That was a joke. @PGriffith was warning you if you don’t know call IA support. Since you asked how to write the query that means you don’t know. Please call IA support. Or, use my link to find help on writing a delete query. Example:
DELETE FROM table_name WHERE condition;
Works fine, thank you very much.
I appear to be having a similar issue.
Showing up in store and forward as “Tag History Data”.
I deleted the tag history provider as you described “OKBoilerData”, but still see theses coming in:
-<cachedata creationTime="Thu May 26 14:46:44 CDT 2022" sourceStore="OKBoilerData">
-<data subtype="" flavor="__datasourcedata__">