How do Ignition client tags refresh with Polling Mode off?

Where does the dataset request travel, and where does it stop?

A client tag lives inside each running client session. When its Expression Type is SQL Query, the client builds the query text, hands it to the gateway, and the gateway runs it through its database connection. The result set comes back along the same path and lands in the tag as a DataSet. Every hop carries a request that starts in the client. The table never sends anything on its own, so no hop carries a change notification from the database back to the client.

With Polling Mode set to Off, the poll timer is gone. The only thing left that makes the tag re-query is a change in its own evaluated query text. Nothing can detect a change in the table unless something reads the table. You have two ways to deal with that:

• Have an operator action force the re-read.
• Poll something small and use it to gate the large query.

How do I build the dataset tag so something external can re-fire it?

Put a value you control into the query text. When that value changes, the text changes and the tag re-executes. A Boolean works well because toggling it always produces a change.

1. Create a client tag named trigger with Data Type Boolean.
2. Create a second client tag with Data Type DataSet.
3. On the DataSet tag, set Expression Type to SQL Query and Polling Mode to Off.
4. Enter the query with the trigger substituted on both sides of an always-true comparison:

SELECT * FROM table WHERE {[~]trigger}={[~]trigger}

[~] refers to the client tag provider from inside a client tag expression. When trigger is false, the gateway receives SELECT * FROM Table WHERE 0=0. When it is true, the gateway receives SELECT * FROM Table WHERE 1=1. Both predicates are always true, so the returned rows are identical. The query string is different, though, and a new query string is what makes the tag execute again.

Check before moving on:

1. Run the SQL on its own against the same database connection and confirm it returns the expected rows.
2. Open the client and confirm the DataSet tag populates on startup.
3. Edit a row in the table and confirm the tag does not change. That confirms polling is really off.

How does a button toggle the trigger?

Put this script on the button's actionPerformed event. It reads the current trigger state and writes the inverse:

value = system.tag.read('[Client]trigger').value
system.tag.writeToTag('[Client]trigger', not value)

Use not value rather than writing a constant. Writing True every time changes the query text only on the first click. After that the text is identical, and the tag has no reason to re-execute.

Check:

1. Put a label bound to trigger next to the button and click the button. The label should flip on every click.
2. Change a row in the table, then click the button again. The table or component bound to the DataSet tag should show the new row.

If the label flips but the data does not change, the break is on the query side. Go back to the previous section's checks.

Can a script write the dataset directly instead?

Yes. Drop the SQL Query expression and let the button run the query and write the result.

1. Create a client tag with Data Type DataSet and no query expression. In this example it is named Scripting tag.
2. Put this script on the button's actionPerformed event:

data = system.db.runQuery("SELECT * FROM table")
system.tag.write("[Client]Scripting tag", system.dataset.toDataSet(data))

system.db.runQuery sends the query through the gateway and returns a PyDataSet. system.dataset.toDataSet converts that result into the DataSet type the tag holds. With this method there is no trigger tag and no dummy predicate. The data is exactly as current as the last click.

Check: click the button and confirm the tag's row count matches a direct SELECT against the table. A spelling mistake in the tag path, including the space in Scripting tag, makes the write fail. The error appears in the client's console or error popup.

What breaks after commissioning?

For an automatic refresh without re-reading the whole table:

1. Create a polled client tag that runs a single-value query. Good choices are a row count or the maximum of a last-modified column. The column name is specific to your schema.
2. Reference that tag in the dataset query in place of trigger. If the value is a string or timestamp, quote it on both sides, for example WHERE '{[~]marker}'='{[~]marker}'.
3. Keep the dataset tag's Polling Mode at Off.

With this arrangement, the full query runs only when the marker value changes. This is still polling, but each poll moves one value instead of the full result set.

How do I prove the refresh works end to end?

1. Open two clients against the same gateway.
2. Record the row count of the DataSet tag in both clients.
3. Insert or update a row directly in the database table.
4. Confirm neither client changes. This proves polling is off and that nothing else is refreshing the tag.
5. Click the refresh button in client A. Client A shows the new data within one query round-trip. Client B stays stale, which confirms the refresh is scoped to one client.
6. If you use the trigger method, click the button again with no database change. Client A re-queries and shows identical rows, which confirms the toggle fires the query on every click.
7. If you use the change-marker method, change a row, wait one marker poll interval, and confirm both clients update without any clicks.

FAQ