Tag Historian has dynamic functionality on at least some level, but it can't allow queries with context(tag value when the machine is in a given state).

Transaction groups are basically mandatory for this functionality, meaning any well designed, extensible project based on historians referencing parameterized UDTS that was coming along is forced to drop that and go to a manual process where you pass around hardcoded database table names and add new machines by individually adding every tag in every identical machines.

Transaction groups are too necessary to be this static.

Crazy that this still isn't a thing, extremely painful process currently

This is currently a pain point for us. Our current solutions involve writing scripting tools that generate XML for the TGs we want, with the appropriate parameters replaced, and then importing them via a gateway script. This process is really manual and not something we enjoy doing, but especially for synchronizing data from a DB to PLCs, this is the only way we can make it work. We want to leverage transaction groups more, but without a way to "UDT-ify" (for lack of a better term) them, there is a lot of headache involved.

Still need this. When adding additional PLCs to log identical data, t's too easy to 1) enter the wrong address -or- 2) point to the wrong PLC or forget to update the item to point to the new PLC. Exporting, making changes, then importing is an improvement but there are still plenty of opportunities to make a mistake.

After reading Kevin's comments today (May 25, 2016), I think what I'm trying to say in my other comment is to have the option to map the parameter used for tag's OPC Item at the Folder level.

When this is done, it would be great if a parameter could be used for referencing the OPC Item for a particular PLC connection.......then have this parameter defined at the "folder level" where all the transaction groups within a folder reference the folder's OPC item (PLC connection).

Some applications have multiple transaction groups within a folder that all read data from the same PLC. Then this needs to be replicated identically, except read the data from a different PLC. Currently, this is difficult as one needs to change the OPC Item referencing the PLC connection for every single tag in each transaction group. Not only is this a lot of work, there is a huge opportunity for error not the least of which is failing to change a tag or two within a transaction group. If this happens, then the data being written to the database is invalid with a mixture of data from multiple PLCs which could mean data from multiple locations logged as data from a single location. This places a lot of pressure on the programmer and no one is perfect.

The ideal solution would be for each transaction group within a folder to reference the folder's OPC Item by using a parameter then have the folder have a place to define a default OPC Item that will be used if a particular parameter is used. Think how easy it would be to add a new location.......just copy the old location's folder then use it to create a new folder. Open the new Folder (not the transaction group's within this Folder) and change the OPC Item and then all the tags within all the Transaction Groups within that folder would be pointed to the correct PLC at the new location. Get the OPC Item name correct in that one location and every single tag within the that folder would be correct. The difference could mean getting it right once versus getting it right 300 - 400 times if you have that many tags within the Transaction Groups located within that folder. So much faster and much less chance for error. It would sure relieve a lot of stress for the programmer.......get one location right and it's then easy to get subsequent locations right.

Would this include the ability to use the parameters in a data type instance to define the scan classes of that particular data type?