I'm back with more information.
There is one rule for tags:
Only one data source can feed one tag.
Or... there is a one-to-one relation between the Point Source and the PI Point.
Which effectively means that updating a PI Point from two sources (one of them being the interface and the other one being your application) is not supported and may lead to undesired behaviour.
Besides that, the only way for you to write values (with either method) is to use a timestamp that is behind the snapshot stimestamp. The reason for this is because the PI Buffer Subsystem has a 'contract' with the source of that PI Point which is used to keep the compresion, we can't guarantee compression of the input of that PI Point if the snapshot value is changed, but any change to (or addition to) a stream with a timestamp older than the snapshot will not affect compression and is, therefore, allowed.
So, in order to make sure it won't fail you should not try to write values which timestamp is newer than the snapshot for PI Points that are being lock by the PI Buffer.
Yes it will work if you keep these recommendations in mind. There are the common failure scenearios you have to take into consideration (network disconnection, server shutdown, power failure, etc.) and the fact that there is no buffering for the PI SDK just yet, so you'll have to handle that kind of situation.
Or pray for your application to work while you wait for the PI SDK Buffer to be released (which is planned for the 1st quarter of 2010). [8-|
Thanks for the clarification. this is largely as I expected, though from additional testing I'm of the belief at this point that UpdateValue() is bypassing the snapshot in all cases and writing straight through to history?
The "only one data source can feed one tag" guidance is interesting as well. This is as I understood it wrt buffered points. That being said, cases arise from time to time whereby it becomes necessary to backfill data (using UFL for instance) to a set of tags whilst those tags are being fed by a real time interface (such as OPC DA). I'd be interested to hear OSI's guidance for how best to manage this. Ie, there's a data disruption, a data gap develops. Eventually the cause of the disruption clears and real time data flow resumes but there's still this gap. we want to fill the gap while the interface is online. Seems like a pretty common scenario?
Well, if the point is marked as buffered by the PI Buffer Subsystem then the snapshot is untouchable, if you manage to get to it the call will fail (either PI API or PI SDK).
Why don't you try using UpdateValue() with a point not being buffered and watch how the snapshot behaves?