SQLTags Configuration Overview

While the goal of SQLTags is to create an easy yet powerful tag model, the variety of options and terminology can sometimes make configuration confusing. The goal of this chapter is to provide a clear overview of the SQLTags landscape, and provide a clear guide to the configuration of various architectures. It will be useful to have a working knowledge of what SQLTags are and how they executed, described in the section What is a SQLTag? in the Project Design chapter.

SQLTags Providers and Drivers

At the highest level of configuration is the SQLTag Provider. A provider is a tag database (a collection of tags) and a name. An Ignition gateway can have any number of tag providers, and therefore the name is used to distinguish which provider a tag comes from.

Every provider holds tags, but not every provider is a SQLTag driver, or tag executor. Some tag providers simply make tags available to use, and the tag execution is performed by a different driving provider elsewhere. For example, the Database Provider is a SQLTag provider that simply watches a tag database stored in an external database. It does not execute tags, it only monitors the values of the tags present. Somewhere else there is a tag driver such as a Driving Datasource Provider or a legacy FactorySQL that is executing the tags and storing the values to the database.

Realtime vs. Historian Providers

As discussed above, all SQLTags reside in a tag provider and provide realtime values. Additionally, there is the concept of tag historian providers, which can store and query historical data for tags. Each tag can optionally have a historian provider assigned to it to whom it will report value changes for historical storage.

Realtime providers - Internal vs. External

The SQLTags "tag database", or how SQLTags tag configuration is stored, can take two forms. In the external form, tags are stored in a SQL database, outside of Ignition. For internal tags, the configuration is stored in the Ignition internal configuration file, next to windows, groups, etc. The two different storage mechanisms have different pro and cons, and so it is a good idea to acquaint yourself with each of them.

External SQLTags Providers

SQLTags were originally invented as a way to reliably bridge realtime status and control information through the database. Therefore, the external storage of SQLTags represents the original methodology, and in fact is why SQLTags have their name.

There are two possible external SQLTags providers in Ignition:

The driving provider, as mentioned above, will execute tags as well as make available tags driven by other external drivers looking at the same database, such as other Ignition gateways using the driving provider, or legacy FactorySQL installations.

The primary benefit of external providers is that the data is stored in a central database, and is therefore accessible to other consumers besides just the local installation. In this way, it is possible to pull together data from geographically dispersed sites into a central location, and then make the data from each site available to all of the others.

The negative side to external providers is that all tag values must be written to the database and then polled for change, which is less efficient than holding them in memory as the internal provider does.

Internal SQLTags Provider

As mentioned above, the internal SQLTags provider stores the tag configurations in the Ignition gateway. The tags cannot be accessed outside of that particular gateway, but in return the efficiency is much greater, as values do not need to be written to the database and polled. It is possible to create multiple internal providers per gateway.