(pidiag -connectionhistory)

Support the collection and retrieval of PI / Windows user information by the connection history database.  

Currently, the connection history database only stores IP addresses which can be misleading when multiple multiple users work from the same computer.

Recovering a PI tag that was deleted accidently is extremly annoying.
Why do I have to create a new tag and reprocess all historical archives to convert the old tag to the new tag in the archives? (https://techsupport.osisoft.com/Troubleshooting/KB/2651OSI8/)

It should be quite easy to just recreate the original tag if you have the pointid and recno. Maybe when deleting a tag you should only mark the tag as deleted instead of removing it from the pi point table.

To take full advantage of AF and substitution parameters it would be great to have a sort of type ID. Now i have to rename all tags to gain this possibility. It would be easy if i could use a portion of the tag name and a  type id. Then i could deploy AF templates with substitution parameters really fast.

Customer would like to be able to loop future data.  For instance since yearly temperatures are about the same every year for a given month, it would be nice if only one set of the projections are stored somewhere and just repeated again and again every year.

If a tag is edited to use a new digital state set, this set will be used for all future data even though the previous state set is still used for historical data.  If a historical archive (prior to editing the digital state set used by the point) is reprocessed, the events within the archive will be coerced to the new digital state set.  This can be very confusing if the archived data is intended to be the old digital state set.

It would be helpful to determine which users or applications made heavy requests to the Data Archive Server.
This could be an option to be activated or not.
Logging the ip, user identity, concerned tags, duration of the request
Those information are actually available in PI SMT but there is no way of storing and analyzing them.

Many of the tuning parameters have units, but the unit can only be found in the tuning parameter's description and is not written consistently (sometimes written in full, sometimes abbreviated, sometimes written as a symbol). Linking the tuning parameters to the UOM database would clean this mess, allow the user to input tuning parameters in different units, and allow the user to convert existing tuning parameters to different units for easier interpretation.

Background:
On a Data Archive where many points have been deleted, there will be many unused record numbers. Since the size of an archive file is tied to the highest existing record number (for performance reasons), this can result in archive files that are much larger than necessary.

Request:
A method to eliminate unused record numbers, likely by modifying record numbers. As an example, three points with record numbers 1, 3, and 10 would turn into record numbers 1, 2, and 3.

Proposed features

• search for TAGS in PI SMT using also logical operators (like AND, OR and NOT) to refine the search criteria

-  search for MESSAGE LOGS in PI SMT using also logical operators (like AND, OR and NOT) to refine the search criteria

Examples

Tag Search
Tag Mask: temperature AND pressure

Message Logs

Message 10.0.0.14 OR 192.168.10.15

As a Pi Admin, it would be usefull to be able to locate the Precommit directory used during the PI backup process to a different location from the Backup directory

While the recovery mechanism for queue corruption is much more robust on newer version of PI Data Archive compared to previous versions, there are still few cases where PI Data Archive does not fully recover from ungraceful shutdowns. PI Server should recover from any ungraceful shutdowns

The ability to define and rollout compression standards on tags across the enterprise / sites. 

When this information is captured bottom up from sites, bad settings make it difficult to maintain a standard which inhibits cross site data comparisons.

Currently, if you want to store predictions for 1 day, 2 days, 3 days, etc. into the future, you must create a different PI tag for each distance into the future.

Future data tags should support 2 timestamps: the timestamp that the predicted value applies to and the timestamp of when the prediction was made.

The additional continuous time dimension will make it much easier to analyze the change in accuracy of prediction as the distance into the future changes.

Currently, the Data Archive stores the timestamp of an event as well as it's value. It would be useful to also store the timestamp at which the event arrives at the Data Archive (perhaps this could be a configurable option set for individual tags). This would be very useful for example in situations where events are written in batches or for tracking down Out of Order events.

When force shifting an archive, the following message is displayed:

"Warning: This shift will clear data from the target archive. Are you sure you want to force an archive shift on <serverName> to a new archive?"

When Auto Archive Creation is enabled (having a value in Archive_AutoArchiveFileRoot), this is very misleading. A new archive will be generated and no data will be wiped.

This warning should only display if auto archive creation is not enabled and the archive will shift into the oldest shiftable archive.

A powershell method for reprocessing PI Archve Files.

$myPIArchive = Get-PIArchiveFileInfo -Connection $myPi -Name "someArchiveFile"

$myPIArchive.ReprocessArchive -NewFileName $false|"filename" -Type Dynamic|Fixed -OtherCoolOptions

Reading data from a reprocessed archive is significantly faster, so I am adding this as a maintenance-task currently using
cmd /c "%PISERVER%\bin\piarcss.exe -if old -of new"
(For some reason start-process didn't work for me)

I would also love a $myPIArchive.LastReprocessedTime for housekeeping. I am currently storing that in a separate hashtable.