From a pharma/biotech user perspective, I am finding that the PI Auditviewer application is difficult to use and conduct an investigation with over an extended time period.  I believe the application needs an overhaul to allow for, at minimum, the following enhancements:
Mass import and scanning of audit source files.  A user should not have to individually browse to, add, and scan each individual log file.  Current functionality does not easily support an investigation that must take place over a broad time period.  Better yet, the application should automatically scan the log file directory, and all audit log files should be searchable by the user after the application has loaded, without having to manually add anything.In addition to the existing Start/End time search criteria that exists today, the search feature should allow additional text-based filtering options.  A user should not have to manually inspect multiple pages of returns, and re-set the filtering on a page-by-page basis as it works today. If the application is not enhanced to automatically scan all available log files when the application is open, there should be a way for the user to save their view/profile.  When the application crashes (for example when initiating a Print Preview with a large number of records returned in a search), you lose all of the added/scanned log files and you have to completely start over.  Also, if a user closes the application to log off the PI server, currently all work is lost as well. Organization of the data is not efficient to review, with each row returned containing at minimum one additional row of nested data, and in some cases multiple rows of nested data.  Each record should be in a single row without anything nested if possible.Printing capabilities require significant enhancement.  Printed output currently contains a summary page with information about the search, followed by a display of the audit records that is challenging to read.  For example, a report from my system showing add/edit of 23 PI tags results in a summary page plus 48 pages worth of audit information.  When a row/record spreads across multiple pages due to the page not being wide enough, there ends up being some blank pages and some pages with very little information contained in the printout.  Additionally, “Good Documentation Practices” type of requirements, including header/footer information indicating a title, the date/time of the print, and pagination in Page x of y format should be included.  This header/footer information is required to link each page together as a complete package without additional user effort.  If not automatically included on each printout, there should be a user option to add this information in custom header/footer fields. Thanks for your consideration in this matter.

Right now there is a PerfMon counter for Buffer Health.  It's either 0, 1, or 2.  That's not helpful because it doesn't tell you what is wrong.  There are other PerfMon counters for Remaining Queue capacity and Points with Post Errors.  The Buffer Manager allows you to change the threshold on when Remaining Queue capacity flags the Buffer Health as Warning and Error.  We set that tuning parameter to a crazy high value because we just have an Event Frame based on the Remaining Queue Capacity PerfMon counter tell us when the capacity is low.  Otherwise we have redundant Even Frames.  We would like a similar tuning parameter for Points with Post Errors so we can similarly disable it.