# Uncertain\_InitialValue for query tags after update from 8.1.45 to 8.1.55

**URL:** <https://forum.inductiveautomation.com/t/uncertain-initialvalue-for-query-tags-after-update-from-8-1-45-to-8-1-55/117405>\
**Category:** Ignition\
**Tags:** ignition81\
**Created:** [October 9, 2026, 6:00am UTC](https://forum.inductiveautomation.com/t/uncertain-initialvalue-for-query-tags-after-update-from-8-1-45-to-8-1-55/117405 "2026-10-09T06:00:26Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ervin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ervin/32/57644_2.png) [@Ervin](https://forum.inductiveautomation.com/u/Ervin)\
**Post date:** [October 9, 2026, 6:00am UTC](https://forum.inductiveautomation.com/t/uncertain-initialvalue-for-query-tags-after-update-from-8-1-45-to-8-1-55/117405/1 "2026-10-09T06:00:26Z")

</div>

Uncertain\_InitialValue for query tags after update from 8.1.45 to 8.1.55

I intended to update all 6 gateways FrontEnd-Master and Backup, IO1-master and backup and IO2-master and backup

I started with IO2-backup and followed with it's master, but I have this problem on it and untill I do not find how to fix it, I do not dare to update the other IO servers.

all my query tags (that are part of UDT instances) are stuck in Uncertain\_initialValue

I restarted the gateway (gwcmd -r) but does not help.

I have this kind of behaviour sometimes when copy-ing UDT instances, and know how to fix this on individual cases,  
If I rename an rename back the instance, all components of that UDT instance starts to work. But now I have hundreds of these and even if I solve a few, when I restart the gateway, they stop working again.  
I cheked all to have valid TagGrpup names on it (since I know ths can cause this phenomena), but even after correcting unavailable TagGroupNames, after a gateway restart, the working UDT instances tags (put to work by rename+renameBack) ar no longer working.  
And even the ones that had valid TagGroups on them before the update are not working.

I think this is not necessary a version update bug, since this kind of scenarios I did encounter ocasionally, but isolated to the tags I worked at that point. OBS: 99.9% of all my tags are by UDT's

I even did a force Re-Sync after updating both master and backup gateways of IO2 and restarted master, but same thing happens

Not a permanent solution either to change something in each UDT definition each time I restart the gateway.

OBS: Since implementation 3 years ago, I deliberatley renamed the TagGroup Default to Default\_ so I never use that by mistake.  
In one UDT, an expression tat used these Query tag values was however left as Default. I changed itto an appropriate TagGroup, but did not help. and even the ones that were already set to a valid Tag Group are stuck in Uncertain\_InitialValue

I even have an UDT instance that has a single tag as query tag on it with valud TagGroup before upgrade, but it too is stuck on Uncertain\_InitialValue

The tag Group for these query tags (named "DBStaticData") is set to Mode=Direct, Rate=60000ms, DataMode=Polled

I did restart the gateway in the recent past without this happening. neither on IO1 or IO2

Please advise

---

<div class="post-metadata">

**Author:** ![Ervin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ervin/32/57644_2.png) [@Ervin](https://forum.inductiveautomation.com/u/Ervin)\
**Post date:** [October 9, 2026, 6:18am UTC](https://forum.inductiveautomation.com/t/uncertain-initialvalue-for-query-tags-after-update-from-8-1-45-to-8-1-55/117405/2 "2026-10-09T06:18:55Z")

</div>

What I noticed, that under diagnistics it says IsLeased true, however it is set to Direct and not leased by the Tag Group

I think I found the problem: Execution mode was set to Event Driven and not TagGroup. so if the database value never changes, it will not get a value on startup???

Changed Execution mode to TagGroup and it solved the problem.

let me restart the gateway and see if the problem is solved

---

<div class="post-metadata">

**Author:** ![Ervin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ervin/32/57644_2.png) [@Ervin](https://forum.inductiveautomation.com/u/Ervin)\
**Post date:** [October 9, 2026, 6:43am UTC](https://forum.inductiveautomation.com/t/uncertain-initialvalue-for-query-tags-after-update-from-8-1-45-to-8-1-55/117405/3 "2026-10-09T06:43:58Z")

</div>

My main problem is solved this way, but I ask my self (and you guys) now: setting the execution mode to Tag Group how to configure the tag group for these static db query values (that does not change ony ocasionally or never) in the way they do not necessarily reevaluate themselfs if these database values do not change over time only on some manual correction updates or new instances. I currently have it set to mode=Direct, Rate=60000ms, DataMode=Polled and the rest by default

especially that I run into another problem: (in the same UDT) i have two expression tags that use the query values. both expressions are EventDriven with another valid TagGroup, but only on eexression did evaluate automatically, and the other is stuck in Uncertain\_InitialValue. I do not consider right to set an expression binding to set it to fixed tare or periodic via TagGroup. why could it not detect the event that it's expression components changed their state or value?

---

<div class="post-metadata">

**Author:** ![Ervin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ervin/32/57644_2.png) [@Ervin](https://forum.inductiveautomation.com/u/Ervin)\
**Post date:** [October 9, 2026, 6:51am UTC](https://forum.inductiveautomation.com/t/uncertain-initialvalue-for-query-tags-after-update-from-8-1-45-to-8-1-55/117405/4 "2026-10-09T06:51:40Z")

</div>

Even if I change the expression tag to FixedRate=20000ms it still does not evaluate. and the rename trick is not working for this expressions issue either. is stuck for good in Uncertain\_InitialValue. even if the query tags are now working.

No ideas left how to fix this one

---

<div class="post-metadata">

**Author:** ![Ervin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ervin/32/57644_2.png) [@Ervin](https://forum.inductiveautomation.com/u/Ervin)\
**Post date:** [October 9, 2026, 7:09am UTC](https://forum.inductiveautomation.com/t/uncertain-initialvalue-for-query-tags-after-update-from-8-1-45-to-8-1-55/117405/5 "2026-10-09T07:09:33Z")

</div>

Why did query bindings work for years before the upgrade on gateway restarts and now they only work if their execution mode is set from EventDriven to TagGroup as polled on 60000ms after a gateway restart?

---

<div class="post-metadata">

**Author:** ![Ervin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ervin/32/57644_2.png) [@Ervin](https://forum.inductiveautomation.com/u/Ervin)\
**Post date:** [October 9, 2026, 7:20am UTC](https://forum.inductiveautomation.com/t/uncertain-initialvalue-for-query-tags-after-update-from-8-1-45-to-8-1-55/117405/6 "2026-10-09T07:20:43Z")

</div>

I discovered that that expression is not evaluating because it is dependent on a stand alone query tag that has the same issue as it is stuck in Uncertain\_InitialValue. that is still in the old working way as EventDriven. something happened because these worked since implementation for years with many restarts. now I have to spend time to find and change all query tags in both gateways? At least Named queryes are working.

---

<div class="post-metadata">

**Author:** ![Ervin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ervin/32/57644_2.png) [@Ervin](https://forum.inductiveautomation.com/u/Ervin)\
**Post date:** [October 9, 2026, 8:12am UTC](https://forum.inductiveautomation.com/t/uncertain-initialvalue-for-query-tags-after-update-from-8-1-45-to-8-1-55/117405/7 "2026-10-09T08:12:33Z")

</div>

I tested another thing:  
assuming that every time I restarted the master or backup gateway it had a working redundant pair, and because of this it remained working for years. (however I had an update on january 2025 from 8.1.41 to 8.1.45 and had no problems)

I left a query tags execution mode unchanged (on Event Driven) but forced a query change in a way it is the same query but it trigered an evaluation and read the data.  
I forced a resync, and then  
I stopped the master gateway, by /usr/local/bin/ignition/ignition.sh stop  
Tag value kept its value (reading it by RemoteTagProvider from a ForntEnd server)  
but when I start the Master back, that tag went to Uncertain\_InitialValue again.  
same thing happens if i do a restart.

These same UDT and tags exist on the other IO server pair, that is still on 8.1.45 and if I restart that, this does not happen.

---

<div class="post-metadata">

**Author:** ![Ervin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ervin/32/57644_2.png) [@Ervin](https://forum.inductiveautomation.com/u/Ervin)\
**Post date:** [October 9, 2026, 8:44am UTC](https://forum.inductiveautomation.com/t/uncertain-initialvalue-for-query-tags-after-update-from-8-1-45-to-8-1-55/117405/8 "2026-10-09T08:44:00Z")

</div>

If it does matter, the datasource is MSSQL and the Query Type is Select. and the select(s) are as simple as they can be (one single string value on one tag or a simple [14R x 2C] dataset with all rows from one single table on another standalone tag)

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [October 9, 2026, 12:33pm UTC](https://forum.inductiveautomation.com/t/uncertain-initialvalue-for-query-tags-after-update-from-8-1-45-to-8-1-55/117405/9 "2026-10-09T12:33:36Z")

</div>

You should open a support ticket.

FWIW, I don't use query tags at all. Insufficient control over query initialization and inability to use safe parameterization.

---

<div class="post-metadata">

**Author:** ![Ervin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ervin/32/57644_2.png) [@Ervin](https://forum.inductiveautomation.com/u/Ervin)\
**Post date:** [October 12, 2026, 6:25am UTC](https://forum.inductiveautomation.com/t/uncertain-initialvalue-for-query-tags-after-update-from-8-1-45-to-8-1-55/117405/10 "2026-10-12T06:25:16Z")

</div>

I use query tags to read static data for each object (Name, Grouping, location, number, etc.) and put it available as tag value on IOserver to be readily available for the FrontEnd. But not for this purpose only. I also use it in the IOserver to dynamically (expression) compose alarm DisplayPaths based on these values so that each alarm can be traced back and known from which object out of 800+ it came and configured once in the UDT and not for each component of the 800+ objects where on an object there can be tens and hundreds of alarms from various UDTs.  
I have a well defined Tag tree structure to be able to do this. And strategically put UDT instances in strategic tag folders. All my tags of the whole project are via dedicated UDTs so I can maintain each simple buildup brick(componnet) from one place.

These and other values are maintained in the database, and used in many places. Although, for example for the map component they are read in scripts via Named Queries, but to be able to use them in alarms, this was my best idea back than three years ago. And until now, I had no issues with it, even after several restarts of the whole server pair(master&backup) for various reasons. I use these values in all main views and this way I do not need to read each time the same static informations from the database (no DB cache, cache directly on tag).

In each dynamic case of query tags, I use the parameters of the UDT for the query parameterization. and had no issues until now.  
In another case, I have a fixed query, no params for just an up to date 14 row 2column dataset so I can maintain it only in the database and use it in various tags with lookup() expressions.

Wherever possible, I tryed to make ready available whatever preprocessed data is worth it on the IOservers so that the FrontEnd has values readily available.
