2 of 2 people found this helpful
If you create an AFTable by importing, then the table is stored internally within the AF Server as a snapshot of the original table's data. If you create an AFTable by linking, then the source of the table remains as the external source and is queried to obtain the table's contents. So you can create 2 different AFTables both created from the same original source, but you cannot use another AFTable as the source.
1 of 1 people found this helpful
To add on to what David has mentioned, you cannot access the AF Tables via PI OLEDB Enterprise currently. We do have an enhancement request for this functionality in a future release.
Can you let us know what information you would like to get from the tables, and why you'd like to use PI OLEDB Enterprise to access them? Also, how big are these tables? Depending on your use case, there can be a few workarounds:
- Build attributes with Table Lookup DataReference, and access the values via the attributes.
- If you are building PI OLEDB Enterprise queries in an external application, you can query the data source directly from your external application.
- You can take the AF Table and export it to a view definition containing the literal table data. This might work if the dataset is small.
The external table contains some maintenance information about the assets that updates periodically. Basically we would like combine the AF Tree element data and maintenance data. For eg, maintenance details of Well 1, Well2 individually and aggregated information of the production unit that comprises well 1, well 2.
I have tried the option 1 and 2 it helps to an extent.
I tried that option as well. I am able to access the AFTable data and manipulate it through AFSDK application. But wanted to do the processing within AF/AFTable rather than through SDK.
One relief I found was the AFTable can access the SQL Views also , that gives some flexibility.