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

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.

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

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.

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.

Please check because our team needs to know what direction we are going to take and need to know what SF can do now or realistically in the next few months.

I wouldn't be able to tell you if that is correct to assume currently, I would have to check with the guys to confirm it. I just gave you the way I am dealing with it.

Then is it correct to assume at this point that the SF Framework doesn't check all of the columns under the hood to determine what was changed in a row to update the log tables? IE... we would need to iterate through the current row and determine if a column changed and if so then pass the info to a command in SF to add a rows to the SFS tables?

Yep, the original reason was that, and from then on I never got back to trying differently, so this is the way I am handling it.

This post will show you an example of before/after field values that you could use to check changes if you will audit that:

http://forum.strataframe.net/FindPost11127.aspx

As for deleted rows, added rows, I guess the BO's AfterDelete, AfterAddNew, AfterSave and so on would be the places. A base BO certainly would be wise for the task, and you can check the BO.TableName and properties like that to decide whether you want to audit or not.

You mentioned " I am programmatically deciding what I want to audit and then adding an event to the Audit tables through the InserAuditEvent ".

Is the reason you are not setting these as properties in the Security and BO because this was not fully implemented into the framework?

If the above does not work and as you pointed out that you are not using them, could you given me an example assuming 5 columns in a table that has a bo. IE.... tblCustomer with 5 columns. Where would you need to insert code to track changes that could show before and after, deleted rows, and added rows.

What I am asking here is what event code would need to be added and the also what that code would look like. I know that the best place for this code would be in a base bo and then have the bo's inherit from the base bo but to simplify my question just show me a single BO.

I am okay on what you showed on tracking the events. Now I need some on enumerating through the columns of a BO and determining if the column data has changed and if so then then command to send it to the log files. I also know that this would be more efficient done on the database, but need to know about the BO approach.