I have several Query Tags running update statements, and they are executing properly. However, in the tag browser they return show a red error indicator and read “Error_ExpressionEval(“The statement did not return a result”)”.
Given that the query is executing properly, and it should not return a result, is there any way to fix this result? Previously (7.9.12) these types of tags returned a 1, and only showed an error when the query or tag failed to execute.
Query attached below, as well as tag details.
update ttc_overview
set
Blend = 'Testing Blend'
where Tank_Number = '306'
We use them in UDTs for moving tag data into a snapshot / overview table in an easily modifiable and maintainable fashion. It started as transaction groups, but modifying 400 transaction groups is a lot more tedious than updating a UDT query definition.
If you have any recommendations for improving this, I welcome it.
I’d script the whole lot. In v8, with a combination of tag events defined on the UDT (to note changes) and a gateway timer in the global scripting project (to send changes to the DB). I really don’t like unconditional updates to a DB.
While I don’t disagree with Phil about unconditional updates to the DB, this is actually supported - there’s code on the backend to attempt to determine the query type, and issue it to the db as an update/select appropriately- and there’s also a manual query type override, that we’re just not exposing in the UI - I’m not sure why.
@AIO, I can’t guarantee this will work, but if you right click the tag, select ‘Edit (raw)’, and then add a queryType: Update property, do you still get the error on the tag?
I have several identical projects in 7.9.x running the same query process, and my first search results on implementing your solution include your argument against tag events and shared scripts (in 7.9).
How would you recommend making similar changes in 7.9? Just using gateway tag change scripts?
Ideally I’d like to implement a solution that is consistent in all projects, but I realize this may not be possible.
Yes, a dedicated project that had a tag change event script subscribed to all elements of all UDT instances that would be triggers for a SQL update. Same timer event to execute the SQL as needed. Not as self-maintaining as the tag events, but any prospect of editing shared scripts in v7.x are just murder on big installs.
Fortunately, the tag subscription list in a tag change event can be cut and pasted from an editor or an automated process.
