Hey,
I added a custom table to a certain custom driver and lately running into an issue: Where when i retrieve (in QAction) the rows from this table it is different that amount of rows that i see in this table in Cube.
For example:
while running this line
protocol.Log(“Row count | ses_customeChannelEventTable.RowCount = ” + protocol.ses_customechanneleventtable.RowCount.ToString(), LogType.Allways, LogLevel.Level1);
I would get in the log: Row count | ses_customeChannelEventTable.RowCount = 1
While in the Cube i can see that this table has actually 10 rows or so..
I think that the value that is retrieved in the QAction is the right one. but i am not sure why in Cube it is showing that this table has addition rows..
Can you please advise how I can “refresh” the Visual of the table or make sure that there aren’t “Sticky” rows in the table that should not be there?
FYI once we restart the device these “Sticky” rows are removed and not being showed any more.
Thank you.
Hi Guy,
It’s not easy to give a definitive answer with the data provided, but I will try to explain the internal logic and what may be going wrong. However, if the issue can’t be resolved with an element restart or can easily be reproduced, I would encourage you to create a software issue task through the support team where an element export (dmimport) package is provided of the element in question.
The reason it is possible to get a different result in cube versus a QAction when retrieving a table, is that a QAction will receive the data from the SLProtocol process, whereas cube will receive it from the SLElement process. SLProtocol is what runs the polling, triggers and actions for a protocol, while SLElement receives any parameters and their changes when they have RTDisplay set to true, and a few other select cases. SLElement is then responsible for monitoring, trending and resolving relations like viewtables and Dynamic Virtual Elements. If SLElement is not correctly notified of a change to this data, then the processes may be in a desynchronized state. However, I am not aware of any cases that could cause this at the moment.
Another path to consider is the cache in SLNet, once a cube client retrieves data from the server, a lot of it is cached in SLNet, if that cache is not correctly updated when the data changes in SLProtocol/SLElement, then even a refresh in cube will still not display the correct data.
Support may be able to assist you to check the row count of SLProtocol and SLElement using client test tool.
OK. Thank you.