Table tool only returns first row in time period

I’ve been looking at this problem on and off for several days. The table tool is only returning the first row of the selection date range and changes when I change the start date. I have independently confirmed the data is present using MySQL Workbench to query the database.

To check my sanity I have created a window with two tables on it - see below. The one on the left is pointing to a historical tag created by another user. The one on the right is pointing to my historical tag.


One difference between the two is that mine is using a historical tag from a UDT but I can’t imagine this makes any difference once the data is being stored. Another is that they are on different scanclasses. Again this shouldn’t matter.


History setup for the other guy’s tag.


History setup for my tag. (I am logging at 00, 15, 30 and 45 minutes past the hour.)

My scanclass is triggered every 15 minutes.

Can anyone give me some suggestions on likely misunderstanding on my part?

How are you setting up the tag history binding on the table? If the data is in the database, I would guess the problem is with how that binding is set. There are some settings which could cause only one row to show up, such as ‘LastValue’, don’t show bad quality data criteria, and return size. You could experiment with some of those settings.

Thanks for the reply. I didn’t have time to investigate further today.

My idea with the test application was to drag and drop the two tags into their respective tables in exactly the same way. I’ll dig deeper.

One thing that’s different is that the table on the left is bound to an “Opt-Dataset” whereas my tag on the right is bound to a “Dataset”.

What is an “Opt-Dataset”? I can’t find it in the documentation.



An Optimized Dataset is returned when there are >= 10000 rows in the dataset. It’s meant to ease the gateway traffic demands of large return values.

What does the binding on the Data property look like? The only other difference I see right now is on your original post your historical deadband is 0 and the other guys is 0.01 and that might make a difference. But if there is data in the database, I think it has to do with the binding.

Thanks again, folks. Here’s the binding.


Again, I dragged and dropped exactly as with the other guy’s tag which works as expected.

For my 15 minute data logging I created a tag with the following expression:

//Turn on for one minute at 00, 15, 30 and 45 past the hour.
dateExtract(now(0), "minute") = 0
|| dateExtract(now(0), "minute") = 15
|| dateExtract(now(0), "minute") = 30
|| dateExtract(now(0), "minute") = 45

This with the oneshot on the scanclass does the data logging as required.

I seem to be getting the desired response by changing the sample size to “On Change”. Is it that simple?


Interesting. I wouldn’t have expected your deadband setting of 0.01 to work with values of the magnitude shown, if the float is a 32-bit PLC value. They can only represent ~7 significant decimal digits, so I would expect that deadband to disappear into rounding error. Whether that would be interpreted as in or out of the deadband would be implementation specific, which could explain the difference between storing the samples and retrieving them.