Perspective client not showing table data

I have a perspective table with a named query binding that returns data which I can see in the designer but when I run the client, the table doesn't show any data. What's causing this? Tables with manually entered data seems to work just fine.


Does your client have permission to run the named query? (Named queries have their own security configuration.)

How do I check if my client has permission?

Compare the security levels you configured in the project against the security levels you configured on the named query. And then check that your user has that security level (or one of them, depending on how you set it up).

Named query is set to Any and project is Public so should be unrestricted.

Then you will need to look in your gateway logs for errors at about the time you expect data to show up.

I have named query binding to LED displays and those work just fine. I don't see any errors in the log.

If some query bindings work and others don't, you need to study the differences. You'll need to share a great deal more detail for us to be much more help.

So, I've tried 2 named queries. One with parameters and one without. The one with parameters didn't work in a sense that it didn't show any data in the perspective client but did show correctly in the designer. The one without parameters worked and did show data in the perspective client. Any thoughts on why parameters wouldn't work in this instance?

Are your parameters referencing session properties that behave differently in a real client? (The designer is a very limited test environment. You may be making assumptions about what is expected to work there versus a client.) A screenshot of your failing query binding would likely help. Consider adding labels to your view that display the content of the bindings you are trying to use on the query.

My parameters are referencing UDT tags (one memory tag and one expression tag).

Here is a screenshot of the named query that didn't work.

Was this issue ever resolved? I am running into a similar problem. However, my parameters do not use UDT tags. I use a custom prop that holds the current date and the other is a string value.