I only have limited experience with SQL so perhaps am misunderstanding this but trying to wrap my head around things.
I implemented this application from the exchange which uses a SQL table to store and recall user created trends in the power chart. This worked well in testing with one DB and gateway.
However the question came up about using the hub and spoke architecture of having a local gateway/SQL DB and then a central gateway / SQL DB which is one of Ignitions common recommended architectures. Ignition handles the historical data correctly with the Tag history splitter for both SQL databases however the custom table for this app only gets written into the local SQL database. Clients on the central gateway would not have access to the saved trends.
Is there a good way to handle this? I have limited SQL experience so is it possible to link two tables and have the databases replicate between each other? Or is it common to have the central gateway talk directly to the site SQL to query it directly? Or have I started down the wrong path all together and should avoid using SQL tables all together for saving custom data?
We use the tag history splitter like you are describing, BUT we have a central gateway that then also has tables for storing and displaying trend configs there. We have separate applications for accessing the Hub data on the central gateway.
I wouldn't want to try and sync up saved trends, first and foremost you would have to sync usernames across all of the gateways and then not every tag in a Spoke gateway is necessarily available on the Hub gateway.
We have tags that the spoke will create for local troubleshooting/trending that don't make sense to replicate to the Hub, so the History Source on those stays set to the local only.
Might be best to store all trends in your central SQL database and then create a database connection to it from each local Ignition instance.
Once that’s set up, in your local tag trending view, you need to set the database parameter in your SQL calls to point to the central database instead of the local one.
You may need to do a find/replace on tagPaths to ensure they work correctly across both gateways — unless you’ve standardized your tag naming conventions and tag providers between the local and central gateways.
This setup allows clients connected to the central or local Ignition instances to access and reuse saved trends regardless of where they were created.