The ability to return a list of discrete tags and their values sorted by time of change from the tags history.
The return dataset would look something like this:
time, tagpath/name, value
Currently, if the system has several hundred discrete points, and I want to find the root cause of an event, I would have to query the historian and then look through several hundred columns to try and find which tag changed. Having one change per row in the result set is much preferred.
I believe you are describing system.tag.queryTagHistory with a returnSize of -1. See the documentation here.
Close. But that still returns one column per tag. My users don’t want to see a table with 100’s of columns.
They want a table with a couple of columns (time, event, value) and hundreds or rows.
Basically they want to know in what order breakers tripped and sensors alarmed. Like reading a log file.
I like this idea, and should be pretty easy to implement. We’ll look into it soon.
Regards,
It would save me having to write a bunch of python code to do it manually 
Hi Colby,
Hope you had a nice vacation.
[quote=“Colby.Clegg”]I like this idea, and should be pretty easy to implement. We’ll look into it soon.
[/quote]
How soon is soon? 
Haha, thanks for reminding me. I’ll take a look today at how difficult it would be - if it’s not difficult, it’ll be done today. Otherwise, likely around 2 weeks. I’ll post back today about the status though.
Regards,
Ok, it’s done. Basically we’ve added a new “return format” mode- either “wide” (traditional) or “tall”, as described here- to both the binding window and the query function.
The tall return mode works along with any of the other query modes. In your case, for events, you’ll want to use the “-1” return size for “on change” data.
I believe it will be included in 7.1.3- but that depends on how much testing we can do on it.
Regards,
Thanks Colby
How can I tell it which db to use if the history is not in the default db?
You should be able to use tag paths along the line of “[database]path\to\tag”. Where the value inside of “[]” means “tag provider” for realtime tags, in a historical setting it means “historical provider”, which is currently one-to-one with the database.
Regards,
Sorry for not getting back sooner. That did it.