I'm not sure if this exists or not ... please correct me if so ...
I'd believe having documentation on the tables that are created when using an external provider would be beneficial. For example, I've created a Realtime SQLTags Provider (Database Driving Provider) residing within my instance of SQL Server 2005. When peeking in the database, I see a number of tables (sqlt_as, sqlt_core, etc). I'd like to understand their structure and purpose a bit more.
I'm aware that ...
... so I realize my request already has a solution. However, I feel the documentation could be valuable for tying in custom applications directly to the database tables without having to use Ignition as a middle man.
Is this a realistic request? Is their some library or API I'm overlooking?
Well, your quote is from SQLTags history, the “sqlth_” tables, while the other tables you mention are from realtime SQLTags. That quote is much more true for history- the system is doing a LOT of work for you to zipper values up, interpolate values, calculate quality, etc. When it comes to history, I think that us adding additional “query interfaces” (such as history support in OPC-UA, maybe a web service) would be better than encouraging people to work with the data directly.
For realtime, however, full documentation would be a fine idea. We’ve already written up various parts of it for companies who have approached us in the past and want to use the data outside of FactoryPMI/Ignition, such as for web pages, etc. or in the other direction, and want to drive the tags from their own apps. The table structure is really very straight forward, there’s isn’t really any magic involved. Relational tag structures and indexed timestamps that allow us to efficiently determine when tag config/values have changed. The biggest thing you’re missing are the various enumerations: data type, write response codes, etc.
What types of custom apps are you trying to develop? Really what I mean is, how are you trying to use the data?
I develop web applications, mostly ASP.NET … I’ve got a library of code and applications and I’m trying to identify any potential integration opportunities. At the moment, I’m just thinking in terms of displaying real-time data on a web page, whether through static text, visualizations, etc.
Any way I can access and understand the data is useful to me … for example, I could retrieve tag values from the database, perform various calculations and process the results into an RSS feed.
Bryan, I do similar stuff but I used stored procedure groups to update tables in SQL and I used ASP.NET to display “realtime data” I haven’t got the opportunity yet on playing with Ignition still using FSQL but Ignition it seems very powerful with their new historical group. I want to digg into it seems I also log data that I used for process trending on my ASP.NET application.
[quote=“bryan_cook”]I like the idea of a web service …
I develop web applications, mostly ASP.NET … I’ve got a library of code and applications and I’m trying to identify any potential integration opportunities. At the moment, I’m just thinking in terms of displaying real-time data on a web page, whether through static text, visualizations, etc.
Any way I can access and understand the data is useful to me … for example, I could retrieve tag values from the database, perform various calculations and process the results into an RSS feed.[/quote]
I’m going to put together a document that outlines everything within the next day or two, as this has come up several times now, and I’m getting tired of writing it up over and over again However, I’ll try to get you up and running for right now…
Each tag must be in a scan class. Even external tags (tags executed by drivers other than Ignition or FactorySQL) get organized by scan class. Scan classes are defined in “sqlt_sc”, and the id from that table is stored in the “scanclass” column for the tag in “sqlt_core”.
Since the scan classes exist for all drivers (are shared by them), just set your tags to use the default scan class’ id.
The only other thing that you should need to do is make sure that your tags’ “drivername” column in “sqlt_core” is something unique for your driver, that is, not “ignition” or “fsql_primary” or whatever is currently being used.
I’m not confident the docs page is up to date… the driver creates additional tables that are not defined on the docs page When I tried it, some of the writes to the wq table seemed inconsistent if the driver would process the updates so I was hoping for some updated details.
However, I’ll try to get you up and running for right now…
When I tried it, some of the writes to the wq table seemed inconsistent if the driver would process the updates so I was hoping for some updated details.