1 of 1 people found this helpful
Static attributes, i.e. attributes with a null data reference, are not historical in nature and generally have one timestamp. Technically this timestamp is not 1970-01-01 but rather the EffectiveDate of the Element.Version. One could save values with specific dates by creating new Element versions, but I generally try to avoid that.
If you are going to have no more than a handful of dates, consider an AFTable and the Table Lookup data reference. If you have more than that, you really should use the Data Archive to historize your data. Given the question, you seem reluctant to do this. May I ask why?
If you never want to historize an attribute, then you will need 2 static attributes: one to hold the value and the other to hold that value's DateTime.
I agree, I don't want to use versions. We are experimenting with moving away from table lookups of data that comes form an external database. We have about 200 of such attributes. Since you asked, I find it hard to accept making a PI tag for something that won't change. I have done so, many times and I understand for some EA customers with unlimited tags, this is probably OK. I used to use ModuleDB properties back in the old days and when we were using RtReports. But now Coresight is the favorite tool and it seems to choke on loading lots of assets with lots of attributes. As I pointed out, and you confirmed, I can use the Attribute/Child Attribute, one to hold the value the other to hold the timestamp, but that won't look very intuitive to visualization people.
1 of 1 people found this helpful
What you describe appears like a valid use case for Table Lookup to me. If you like to move away from referencing data that is stored in external databases, you can create the table directly in AF. It's also possible to Import the data of an external table and to create an AF table with this data.
EDIT: Sorry, I have used the wrong wording. Instead of creating a Linked Table, you create a Table Import. This will persist the external table in AF. Please note that changes to the external table will not automatically reflect in the imported AF Table.
Gregor, Thank you for the reply. We are using imported not linked tables, and the asset counts we are talking about are around 6,000. So we do see a delay with bringing all that in to cache. We also found that "linked" option using parameters and getting data directly from external tables, which is the only way to get current data into a table without manually re-importing it, was extremely slow!
I was speculating about a few things:
(1) The attributes with <None> have values/timestamps that are coming directly from PI AF, i.e. - kind of behaving like "static" or constant values. - there are 5 of these type attributes and some of these are String Builder and use attribute values from the table lookups;
(2) The attributes with Table Lookup references, are getting data from PI AF too, via the "imported" tables, each requires a SQL statement for each element/attributes - there are 55 of these from three different tables;
(3) The PI Point referenced attributes are getting current values/timestamp, so that seems quick enough - in my use case I have 55 of these - I'm going out on a limb here and saying that the performance of bringing in these values to AF Cache is good.
My theory is that if leave the PI Point references alone but remove any table lookup references and instead use <None> and populate the values with a service, only if they have changed, that the client cache load will improve, and I hope, significantly.