I just had a talk with our data-management guy and he’s pretty dissapointed that transaction groups store data with a column for each tag instead of having a ‘Tag-ID’ column with all the tag names.
Can this be changed so that the tabel layout is like that?
He would like a tabel with five columns with ‘ID’, ‘Tag-ID’, ‘Value’, ‘Timestamp’, and ‘Quality’.
These columns should then just be populated with all the transaction group data.
Another question: Is it possible to store custom data through transaction groups? Like what if I want to store a tags EngUnit? Or EngLow and EngHigh? Can this be done?
[quote=“Esn, post:1, topic:15893”]
I just had a talk with our data-management guy and he’s pretty dissapointed that transaction groups store data with a column for each tag instead of having a ‘Tag-ID’ column with all the tag names.[/quote]Heh. I consider wide rows the most important feature of transaction groups.
[quote]Can this be changed so that the tabel layout is like that?
He would like a tabel with five columns with ‘ID’, ‘Tag-ID’, ‘Value’, ‘Timestamp’, and ‘Quality’.These columns should then just be populated with all the transaction group data.[/quote]
No, but the tables produced by the Tag Historian are set up like that. You might want to switch methods.[quote]Another question: Is it possible to store custom data through transaction groups? Like what if I want to store a tags EngUnit? Or EngLow and EngHigh? Can this be done?[/quote]Yes, just add a dot and the appropriate attribute name.
[quote]Another question: Is it possible to store custom data through transaction groups? Like what if I want to store a tags EngUnit? Or EngLow and EngHigh? Can this be done?
Could you provide a little more detail in how to configure the setup in the quote above?
You can't just drag and drop. But you can start with it to get the base tag into the transaction group as an item. Then open the item details and adjust the tag to include the attribute.
You should take a look at Block Transaction Groups. While is doesn't do the "Tag-ID" by name, I've gotten around it by setting up a static table with the "friendly name" and an integer containing the row-id used in the main table. A join in your query can tie it all together. Your whiny data-management guy can help with that...
Sorry, couldn't resist...
If you can see the attribute in the tag tree, you can drag it into the group.
Heh. I didn't say I liked it. I just said it could be done. Hence, the whiny data-management guy.
In my case, as an assembly plant, a part can be tested up to three times (two-retries). It makes more sense in those instances to store the raw data in a block, but it's a lot more difficult to pull it back out out into a sensible, friendly format.
It's not often I get to get to teach the master. I think that gets me up to 2% in catching up to you.
