Glad if any one could please give some more infor on
The question is a little vague. I've written one or two DR's and I must admit is pretty efficient; obviously you can destroy the efficiency in your code. The documentation is vague; but there is a white paper on this site which give a few clues and the examples really help. The most important thing to bear in mind is that DR's actually run on the client not on the server. This is a double edged sword in many respects. In my experience the area to focus on is data calls to the backend systems. These should be minimised; i.e. don't read interpolated data if you don't need it, limit that amount of data being called, limit the amount of data being written. I would also advise that you use the GetInputs method rather than reading attributes in the GetValue or GetValues methods.
Hope this helps.
Thanks for the quick reply. I am trying to extend the Table Look up.
For GetValue--> It gets data from the AF Table
For GetValues-->It gets data the from the Source( A huge table)
i want my Data Reference to be efficient, So that calls to Multiple attributes are rationalized if they belong to the same table.
Please have a look at my post
[DEAD LINK] vcampus.osisoft.com/.../7387.aspx
The AF SDK has a built-in cache that caches some AF objects.
AF-SDK HelpThis class caches certain AF objects and collections to prevent them from untimely garbage collection.
This effectively caching things like the AF Attributes and Elements. However, if you have two attributes with DR's then I suspect that AF will treat them as two distinct objects; which defeats what I think you are trying to do. However, if you have 5 DR's that use a common set of 10 attributes then the AF cache will help as the 10 attributes will be cached on the client (AF developers are welcome to chip in on this point).
The externally linked AF Tables may go some way to achieving your requirements. AF Tables are run on the server and they query the rational database and store the data in a memory; to the best of my knowledge the data is not stored in the AF database. The table lookup DR's then read this data from the AF server. Therefore, your objective of hitting the relational database only once is achieved. There are however, some potential problems with this; the external data can only be updated on a time basis (you can configure the AF table to update every x number of seconds), you would have to store all the information required in the memory of the server which could become a limitation depending on how much data you need. Bear in mind that you can't alter the query of the AF tables from an attribute, so you would have to load all the possible data into the AF Table (and therefore memory). This is what has put me off from using AF table for large chunks of data; I will always find that one users who want to see the data from 2 years ago.
My preferred approach has been to use the RDBMS interface to read the data into PI and then use PI Point DR's. This is basically solution 3 from your previous post. The distributor strategy (see the RDBMS manual) means that the relation database is only hit for data once per update. I normally configure AF to create the PI points. This strategy has the advantage that the data access is considerable more efficient and the data is accessible via all PI tools (unfortunately AF is not fully support in all PI tools). The biggest disadvantage to this strategy is that the data is duplicated, this becomes particularly relevant if the data can change. This problem can be mitigated. Sorry I went off at a bit of a tangent here.
Retrieving data ...