PI DA Server should allow for more flexibility in terms of the format of archived data. A big advantage would be if PI could archive two timestamps per event. One timestamp will come from whatever the data source is (PI Interfaces, fiels devices, etc) - this is effectively what PI has now. In addition to that, PI Should be able to add a second timestamp recording when the event got into PI i.e. when either PI Snapshot or Archive Subsystem saw the event coming in their respective queue. Benefits and use cases:
- any PI Client could make sure it gets all new pi events since client last talked to PI. Keep in mind that PI can have lots of backfills going on at the same time as realtime data so it is impossible for a PI Client app to know that since last time it talked to PI, there was a backfill correcting some data for 3 months ago. I know there are consumer queues, but they are not working properly all the time, they can overflow, etc. The more robust way would be if PI knew when it actually got the events.
- PI admins would easily detect backfill operations and asses data latency and anomalous delays. Questions like : when do we get most data into our PI during the day, or when did these duplicate events made into PI, or what is the data latency from field sensors to the PI archive, would all easily be answered. Now it's virtually impossible.

Please upvote if you like.

I see too often customers struggling to find the right exception and compression settings. When exception/compression are not well defined, they end up having too many values or missing values, what causes a lot of problems when the affected tag is being used in other calculations (totalizations, for example).

Consider the tag attributes " zero" and "span": today, values near the "zero" are more penalized than the values near the "span"  value, because the exception/compression deviation may be too big for the values in the lower scale of the entire tag range. It translates in poor dynamic range.

We could have the option to use logarithm exception/compression scale, similar to the mechanism used in telecommunications (A-law or u-law, for example). Small changes near " zero"  would be more prone to pass exception/compression testing than the small changes near the "span"  value. This way we improve the dynamic range of the archive data, which may be very important in a totalization scenario (oil & gas production, for example). As a result, the robustness of the PI System exception/compression mechanism would be greatly improved.

Most of the PI Data Archive information that is accessible from PI System Management tools is perfect for a relational database: PI Identities, PI Mappings, PI Point attributes, PI Message Logs, etc.

Moving all of this to an SQL Server database would make it easier for the PI Data Archive to communicate with:
• PI Asset Framework (which already uses SQL Server),
• PI OLEDB Enterprise (currently responsible for translating SQL queries to native PI requests),
• PI Builder (translates the PI file format to a relational database format anyways), and, most importantly,
• the user (users know relational databases, but they do not currently know how the PI Data Archive stores its information, so they are stuck with PI System Management Tools and its limitations)

The use of an SQL Server database can lead to a simpler, more transparent, more flexible PI Data Archive. There would be less "translation" code for OSIsoft to maintain and the user can write queries to the PI Data Archive more easily.

Most of the time, zero, span, and typical value are unused, cause confusion, and/or lead to easy but costly mistakes.

Typical value is probably the most useless PI Point attribute. It doesn't affect the PI system. It is just there for the user's reference. Why not a range of typical values? Why not calculate it dynamically based on actual data? Typical value is superseded by limit traits in PI Asset Framework, so there is no need to force a typical value on every PI Point.

Zero is mostly used for Float16 PI Points, which is probably rarely used these days. The concept of zero in cases other than Float16 is sufficiently covered by point types having a minimum possible value that they can store.

Arguments similar to the ones against zero can also be used for span, but span has an additional reason to disappear. Exception and compression deviation (E&CD), whether they are specified in engineering units (EU) or as a % of the span, are saved as a % of the span. This means that any edit to the span results in a change in the E&CDs when they are interpreted in EUs, which is an unexpected surprise for the PI administrator if they are used to thinking of E&CD in terms of EUs. After all, EUs are the default way to specify E&CD in PI System Management Tools, so why would anyone think that this is not what gets saved to the PI Data Archive? In cases where the span is increased, this can cause the E&CDs to be larger than intended, resulting in data loss. The mistake is too easy to make (I made it twice already), and it is too tempting to correct the span from its default value when another PI administrator asks why the span does not reflect the corresponding tag in the data source. Many PI Points do not need a span. Just remove it.

I realize that a point class without zero, span, or typical value would mean that the Float16 point type cannot be used and that E&CDs can only be specified and saved in terms of engineering units, but this "sacrifice" is actually very appropriate in a lot of cases.

OPC server is outputting data with the currency data type (VT_CY) and it needs to be stored in the float type.  As per the OPCtoCSV document, the OPCtoCSV tool/OPC interface invokes VariantChangeType in order to convert this currency value to it's string representation before PI receives it.

"Some OPC servers have property values that are type VTCY. The VTCY type is intended to represent monetary values. A VTCY value is a fixed-point number with four digits after an implied decimal point that is scaled and stored as a 64-bit integer. When VariantChangeType converts a VTCY value to string, the string representation is an integer. To account for the implied decimal point, divide the integer by 10000. That is, “123456” actually represents 12.3456 (using dot to indicate the decimal point), “123” represents 0.0123, and so forth. (p. 19)

So essentially, PI is receiving an integer value of the string type that is several orders of magnitude larger than the original.  He needs PI to first convert this value from a string to a float, and then scale it down by 1/10,000.  Typically, a conversion from currency to float would be done on the source before the data reaches PI, but his OPC vendor has prevented this.

As far as I know, the Data Archive is not capable of automatically converting and scaling this event before archiving it.  We tried setting a conversion factor to 0.0001 and changing the point type to float but then we started getting "Bad" values.  The only way I know to accomplish is to create a performance equation that will parse the string value (using Float()) and then scale the result by 1/10,000.  In fact, we did create a test performance equation and it did exactly what we needed it to.

For PI System Administrators, it would be nice to be able to easily get a list of all buffered or unbuffered points on the PI Data Archive.

Currently, a list of buffered points is possible to retrieve using 'piartool -bfs <id> -ptlist', but a comprehensive list would require iterating through all of the buffered sources.

Such functionality would be nice because it would allow administrators to easily identify which data sources need to be configured for buffering, or which data sources are possibly misconfigured for buffering. It would also be a quick thing to check for points which may potentially have data loss during server downtime/server maintenance tasks.