Hi Dojo Community,
I'm facing some issues with the GetTrendDataMessage call, we are using it to retrieve data for some table parameters back in time.
The call works fine almost all the time; however, we found a specific case that is causing the response to be different from the expected.
Here I have the trend data for a specific parameter and entity of the table
As you can see, past ~16:40 we stopped polling data
When the GetTrendDataMessage is configured to retrieve data for any range after it stopped polling, it will retrieve unexpected values (mostly the last known value) instead of N/A or empty or something like that.
Here is an example using client test tool (but the same happens on the driver):
- Message used
Response:
As you can see none of those values are expected to be received:
- The first record has a timestamp outside the defined time range
- The second record does not exist according to the Trend graph in the first image, at 19:31:54 there shouldn't be any value
This is directly affecting the driver logic since it is supposed to put N/A when there is no available data, but instead is setting these non-existing values.
Is there any other method we can use to retrieve data from parameters for a specific time or time range?
Also, is this a expected behavior for that call and the trend data does not reflect the correct data? Or is not working as intended?
The GetTrendDataMessage is designed to return a result set that DataMiner clients can easily interpret to draw the corresponding graphs without having to do a lot of extra processing on that result set. This may result in seeing some data in there that in the first place one would not expect.
There is however the Raw property that you can set to get a result set that matches closer to what is stored in the database. Can you try setting that one to true to see if you then get back what you would expect.
Hi Jeroen
Using that option removes the second timestamp (the non-existing) and leave us only with the record with time outside of the selected time-range.
While this is still unexpected, we are able filter it out by the time because of the same reason.
Thanks!