SQL DB Tags in sqlt_core table not appearing in ignition

We generate our own tags in sqlt tables. I have seen many times where I open a designer and there are no tags available and refresh does not bring them in. If I clear and regenerate the sqlt tables, then the tags will appear. I’m guessing it is to do with the configchange date in sqlt_core. If I update the configchange date on one tag, then that one tag will appear. If I do a sql command to update all configchange values in the table though, no new tags appear. So far I can only get them to appear by recreating the entire table, or updating configchange value one tag at a time. Should ignition be detecting tags that are in the tables that it does not currently have, regardless of the dates on the tags?

:prayer:

This same problem seem to be there in ignition ver 7.1.2 (b5273)

It relies on the config change to indicate new tags, but you certainly shouldn’t need to load them one at a time. I suspect the definition of one of the tags is invalid and is causing an error that causes the load to fail, which is why you can’t load all of the tags at once.

After attempting to load all of the tags (set the config change on all), could you send the wrapper.log file from the install directory to support AT inductiveautomation.com? This file could contain some information- if not, we’ll have to do a little more troubleshooting.

Regards,

I captured the wrapper log and sent it to support as requested. Looking at it just now I see the following complaint that I will look into.

INFO | jvm 3 | 2010/06/28 09:50:50 | ERROR [[IgnitionDemo] ] [09:50:50,489]: Error loading tags.
INFO | jvm 3 | 2010/06/28 09:50:50 | com.inductiveautomation.ignition.common.sqltags.parser.TagPathFormatException: Tag property ’ Check’ is not a valid property.

I found two points with “Synch. Check” in the name. I changed it to “SyncCheck” and now the tags will load. It complained about “Check” but it seems the “.” was the problem.

Ah, yes, “.” is not allowed in tag names. However, this shouldn’t cause all tags to fail to load, so we’ll look into handling the error better.

For 7.1.3, the “.” is still not valid, but at least only those tags should fail to load.

Regards,