@Supriya: PI UFL interface is a good manner to migrate data from one system to the PI System. With UFL you can configure it to read almost any data format inside your flat file. A fast and efficient way to generate a flat file to be parsed by UFL is:
- create a *.csv file
- put one event per row
- store the even as tag, time and value like sinusoid,02/12/2014 06:00:00,1500
One drawback from the the PI-PHD interface is you must fully recover your history before getting current data.
After verifying some past techsupport calls, many customers have picked to use the PI-HDA interface if your PHD system is equipped with an OPC HDA server. It also has an /hronly command line switch that allows the interface to move forward in time pieces, rather than all at once.
Thanks for the response Mathieu.
Can you please elaborate on the drawback of using PI-PHD interface?
I believe in all cases we would need to history recovery data completely before getting current data.. Please correct me If I m understanding something different
Also, Can the data be migrated using Osisoft COM Connector?
If Yes... How it can be done?
PI Server COM Connector for OLEDB Data Sources is a software component that allows OSIsoft client applications such as PI ProcessBook, PI DataLink, etc. to interact with data storage systems other than the PI System Data Archive. In other words, the OLEDB COMCtr allows for exchanging of snapshot and archive data with an external data source through the OLEDB ) interfaces (OLEDB providers). The end user must provide a set of SQL queries, which will map the time series stored in a foreign system to the COMCtr tags. All in all, this product should be used when you want to have access to the data stored on a foreign system without copying it to your PI Server.
I wouldn’t use the PI-PHD interface for a simply reason. I have been working at OSIsoft for three year and I have never heard about this interface which means that it is not very famous among the vCampus community and TechSupport engineers. On the other hand, PI UFL is a known interface among the same public which means that in case you are facing any issue, there are much more people who have the knowledge and experience with this interface that might be able to help you. This is an important point that you need to consider. Nevertheless, you need to make sure the PI UFL will address all your needs.
Hope this helps you!
For one of our customers we had to migrate the complete ten years of history from their live PHD-server into another live PI-server, also with ten years of history.
We have used the OPC HDA interface to make this work. The reason for this was that, as Mathieu Hamel also mentions, is the /hronly functionality. With the PHD PI interface it is possible to retrieve the history, but you cannot set an interval for history recovery. For us, this would have meant that with the PHD PI interface the complete ten years of history should be migrated at once.
With the OPC HDA interface we set an interval of one month as /hronly parameter which took about one hour for our setup. We used a batch-file with the command line parameters for the interface call for each interval to automate the process. We kept a close eye on the load of the PI server, because the piarchss.exe can take up a lot of memory during the migration process.
We also used an OPC DA interface with the same point source as the HDA interface to retrieve the current values.
In the end we migrated the compete history from the PHD to the PI server without any problems.
Production Intelligence Engineer