I have constructed a Named Query to pull and provide some metadata about historical tags that a user selects in a Perspective Session. This query is configured to accept the database name as an input parameter, but that leads to another issue: how can I obtain the database name?
Currently, I allow the user to see and select from the available databases in a dropdown menu by browsing the available system tags (or system.db.getConnections would also work for this, I know). While this technically works, it means that the user can't obtain information about two or more tags at once unless they store to the same database. Obviously, this could be a problem; often, even tags within the same folder or UDT will store to a different database.
I would prefer to dynamically resolve the database name per tag (likely with some form of in-script caching linking a DB name to each history provider for performance?) and batch the queries if possible, allowing the user to select tags as desired without needing to know from which database they are sourced.
I am aware that I can obtain the name of the associated history provider for each tag. However, while usually not the case, I would like this tool to work in the event that the history provider and database do not have the same name. Is there a scripted way to obtain the exact datasource name for a known history provider? That would be an immediate solution to the problem.
Critically, the entire tool must be portable between projects and Gateways (i.e. no caching of relations to a database lookup table, since there's no guarantee that such a table will be available on another Gateway).
Are you saying that you have written a query which pulls data for tags which are configured to use Ignitions Built-in history function? If that is so why do the provided Tag history functions/bindings not fulfill your need?
No, there isn't. Also consider split and multi gateway architectures where the frontend has remote tag providers. Getting this info becomes harder. It is however possible to get via scripting, but it's unsupported... Although if you use the API now on 8.3, it might be more supported than it was before
Yes, but not really. I'm after metadata, not standard historical data.
The direct query is used to identify the database primary key(s) associated with the selected tagpaths (which, as far as I know, is not supported by any of the tag scripting functionality since it's an 'abstracted' operation of the database itself rather than the tag provider)
I don't think I fully understand how it gets harder from a technical perspective? Would love to learn.
Here are my thoughts: in the absence of the case where the Gateway in question has only remote history providers and sends its history requests by proxy to another Gateway, a complex architecture should not alter the function of relating a standard datasource history provider on a Gateway to its datasource name (it must exist somewhere for retrieval if it exists for normal use, right?). In that case, my tool would be run on the Gateway where the history provider exists anyway rather than the 'edge' or frontend Gateway. As an API limitation, such a scripting function could simply document that it can only obtain a database connection name for a history provider that 'exists' from the running Gateway's perspective.
I originally thought that the datasource name would appear in something like a getConfiguration() call for the tag itself or for a historian (8.3 only) or that a list of related history providers for each DB might appear in the dataset returned by system.db.getConnections() (it doesn't).
Regardless, I may be pushing too hard to resolve an edge case that we're unlikely to run into in the first place since the DB connection name and history provider name are the same in 95% of our systems. I just tend to be thorough in chasing down ghosts...
In v8.1, SQL Historians automatically and unconditionally use the associated DB connection name as their own name.
In v8.3, Historian names are arbitrary and the associated DB connection is a setting. Commonly, the same name, and conversions will do this, but up to you. And in scripting, you would have to dig into the configuration in gateway scope to retrieve the DB name for a historian. You really want to use the system.config.* functions, new in v8.3.8, to do this.
Yes, all of my scripting work for the foreseeable future must include cross-version support to be portable across versions (per management's requirement) as our customers are requesting a mix of 8.1 and 8.3 systems and the team wants new internal admin tools to work seamlessly in every system without retooling. It's made troubleshooting and atomicity very interesting and forced me to learn a lot about the underlying architecture of Ignition / how it's changing.
I thought so by observation but wasn't sure if there was a niche workaround. This confirmation helped a lot!