Wrong data in Perspective table

We are replacing the digital signage from our factory, moving from old Visual Studio applications to Perspective screens. I really like perspective since any modification is fast and easy.

We were using ThinClients connected to a virtualization enviroment, formerly running a Windows and visual studio application, and now using that ThinClient (HP ThinOs) just to open the browser with Perspective screens. The screens contains a table showing some information (Product number, weight, lenght...)

Today the operator called me out reporting that the table was repeating the product number in different rows, which is impossible. He entered to the project url from another PC, and was also showing wrong values.
How can face this problem? I mean, is there any log with query result in the Ignition server, or something similar?
The query from the SQL is correct, since is the same stored procedure as the previous visual studio application, but that repeated values can not be possible as far as i understand .

Thank you!

More information required.

  1. Are you using a Perspective table?
  2. What is the props.data binding? A named query?
  3. Can you reproduce the problem in Designer?
  4. If, so, what does the data look like?

You have the option of returning the dataset as a dataset or document. Document allows you to inspect the first couple of rows in the bottom of the binding dialog and you can browse it in the props.data so I prefer that format.

I don't think there is any kind of log unless you create one.

A few more things:
• Has the INSERT query for data entry changed?
• In the database, is the product number field designated as a primary key to require unique values?
• If not, is the INSERT query being ran as a transaction with an accompaning SELECT script to ensure unique entries?

It's hard to know what the issue is based on just this info, but I'd suggest creating a logger in a value change script or something similar and going to Status > Logs on your Gateway and seeing what the data coming in is and also what the data in the table is. To do that:

logger = system.util.getLogger("Name of Logger")
logger.info(str(data to log))

That should at least get you started without knowing anything else about your issue. I will say that I use Perspective tables a lot and have never had them display data that I didn't put into them, so there's a 99.9% that it's getting the wrong data put into it for some reason.

1- You´re correct, i am using a hidden Perspective Table called "Dataset" with a Named Query to get the info.
2- The text fields in the screen are refered as {../Dataset.props.text}[X,Y], with condition based binds (values on the dataset alter "Product number" color for example, weight or lenght flags...).
I never saw that behaviour in the designer, that´s the reason i have no idea how to manage this.

The only difference from the old application it is not calling a stored procedure, I put that code inside the Named Query field to reduce the amount of stored procedure on our database.
I am going to put the focus in @justinedwards.jle message, and tomorrow i will ensure the selection of unique values, or some exception that could produce this.

Thank you!

So, seems all of you put the focus on the data source discarding any misfunction on Perspective Table component, right?

If I'm understanding correctly, you are using a binding on a hidden table to return the SQL data and then binding text fields to specific row and columns in the data table.

As far as I know bindings update when a change is detected on the bound value. I'm wondering if bindings to the data table aren't triggering the update on your text fields for some reason.

I suggest that a better way would be to create a custom property on the view, apply the SQL binding to that and then bind the text field properties to the custom property.

That would be my guess since I have not seen a case where that happened, but logging the data before it goes into the table would help you to rule it out completely

That's correct. I've also seen issues where a data binding doesn't refresh on its own when I expected it to. The solution is to call refreshBinding on the binding.

Also, there is a lot of overhead with using hidden objects to gain a single property on that object. @Matabufalez, consider adding a custom property to something such as the root container, binding that to your query to get the data and calling refreshBinding in a script to refresh the query at a time you are likely to want to refresh it. I like putting properties like this in the root container because it's easier to find them (vs having them on an arbitrary control somewhere on the form.

It's typically a good idea to call refreshBinding on page load if you're seeing pages load with dirty reads.

You may need to poll your data on some interval. This can be done by binding a custom property to the now function ex("now(5000)") and adding a script transform on that to call refreshBinding on an interval. Basically, the now function triggers the binding and the script transform performs the refresh.

1 Like

Finally I could get the picture when the problems was present...
And of course, the solution was easier than we were talking about.
It was just a problem with the text field width, and in some case the number didn´t fit in the text field, showing just the first number, so for example, for piece Id nº40, 41 and 42, the operators were just seeing a "4".

Thank you guys for the ideas and solutions written in here by the way!

1 Like