Trent, I have my meeting today with my Dev Team at 2PM and I need a definitive answer to this thread. Does Auditing work or not as advertised? If so, I need to know and how to make it work with any small example. We do not want to waste our time trying to chase something that does not exist.

Ross,

There is a reason that the "just check it" approach hasn't taken hold.  We don't even use it ourselves in the medical world due to several factors:

1. The check it and forget it approach would produce records client side, a lot of records, then have to move those records to the server.  This in and of itself would be horribly inefficient as there would be WAY to many audit records produced for every live record.
2. Ambiguous and monotonous data would be created making it very difficult to filter through.
3. Prevents triggers and/or client side threads outside of the BO basic logic to be implemented improved performance and reducing overhead.

In our medical application we audit a lot.  But it is thought out and implement where it is necessary instead of just pulling the "log it all" card.  If you want to log it all, then get a SQL Server side auditing tool that interfaces at the server level that will do this for you.  But if you want to create intelligible viewers and log records for your client to use daily, then you will want to think about what you want to log.  Below are a couple of screenshots from our medical application:





In our event viewer (1st image) we have many events, but they are organized and thought out.  This includes field level changes in different areas of the application that captures.  But some of these are not turned on by default and is an option within our application:



As you can see in one of our audit options screens, there are warning signs next to anything that will produce a vast number of audit records.  They can turn it on, but it is an option.  You can wrap security around this as well.  But it is extremely important to think out your audit approach and needs. 

You can combine approaches too.  You can slap an SQL auditor on the SQL side to catch everything.  Then you can get more pointed and specific on the app side.

Hope this helps.

Thanks Trent. This gives me and our Team what we need for our meeting.

As an FYI I finally completed the Auditing for New Rows, Changes and Deleted rows using a BaseBO and the property AuditDataChanges on each BO. Then created a UserControls using an Infragistics grid that can be instantiated to any form's panelManager with a single line of code and of course passing some parameters to it to filter what shows in the grid.

Hello Ross, you PM me a while ago, I´m unable to replay from forum system, error message said unable to find user or user doesn´t exists.

------------------------------------------------------------------------
I would like to change the world, but they don´t give me the source code.
MS Windows 7 Ultimate 64-Bit
Intel(R) Core(TM)2 Quad CPU Q9300 2.50 GHz
6.00 GB of RAM, NVIDIA GeForce 9800 GT

MacBook Pro i5 OSX Lion