I have a named query where I'm passing in a string parameter to the WHERE clause of a SQL statement so the final result looks something like WHERE 'Machine#' + :DryerNo
The issue I'm facing is that when I go to store a value for the parameter, and press OK, the value I enter isn't being saved; I'll enter 2 for example, and then next time I open the component, the value spot will be blank again. The SQL query functions just fine when I test it in the Named Query testing tab, and the pathing for the named query is also correct. It also doesn't seem to happen to every named query I have, only select ones. I'm not getting any error dialog boxes either that would make me think it's an issue with the SQL query, so is this just a matter of invalid syntax?
Named Queries don't store parameter values. They have to be supplied, always, from wherever you use the NQ. How are you using this NQ?
I am using it to populate the data of a table component, and in the table component's data is where I supply the value, and is where the value isn't being stored, sorry for the misunderstanding.
Bind the query parameter to a property in your user interface. If Perspective, set that property to persistent, or arrange further bindings to ensure there is always a value.
That seems to work, I created an invisible label with the text I needed and bound the parameter value to the text of that label. Thanks!
Why would you do that? That will just make future you and your future colleagues confused. Use custom properties on the view (or session) for items that have no place in a component that you actually need to have present. (Similar in Vision: use custom properties on components, containers, or Vision Client tags.)
Ah okay, that makes much more sense. Will use a custom property instead, thanks for following up and saving me from myself
Do you have an idea as to why it wouldn't accept the manually inserted parameter value and instead needs to be bound? I've had luck in the past assigning the values that way.
No clue, but I generally do not parameterize things that are just going to be given a constant.
Wait, you're passing a constant ? Why are you even using a parameter ?
I am using several different screens that are pretty much the same, but the number on each of them is different e.g. 1, 2, 3, etc.
These screens all utilize nearly the same SQL query as well, but where the number at the end of the machine is different.
I figured it would be easiest to use a named query and pass in the relevant number via a parameter.
The inevitable question follows: "Why are you not using one parameterised view for all machines?"
Yep. And even if not all views/windows can be refactored into one, it feels like something somewhere should be templatized.
I'm not quite sure what you mean, could you clarify on where I could set that up? I've never heard of that before. Are you asking why not have one screen with the option to cycle between the parameters?
What do you mean? Is a named query with a parameter not an example of templatizing? I'm open to criticism, what would you do? While I didn't design these screens, I probably also would've done it in a similar manner. These screens don't receive input from a user, and are purely meant to be displays.
Good practice would be to set up OPC tags for a machine in a logical, reusable structure or, better again, with a tag UDT. This permits rapid addition of new machines, etc., and speeds up application development and maintainability. The UDT instances then might be named "Machine01", "Machine02", etc.
Then the Perspective views are created with a view parameter (e.g. "machineID") to take the machine name. The various labels, charts, buttons, etc., have their tag or history bindings use an expression that includes the view parameter.
Now you develop a menu system which calls the one view and passes in the machineId parameter.
Have a browse of Views in Perspective - Ignition User Manual 8.1 - Ignition Documentation and watch the video.