Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
MMNET & Audit Trail
Message
From
03/06/2011 09:03:02
Timothy Bryan
Sharpline Consultants
Conroe, Texas, United States
 
General information
Forum:
ASP.NET
Category:
The Mere Mortals .NET Framework
Environment versions
Environment:
ASP.NET
Database:
MS SQL Server
Miscellaneous
Thread ID:
01512531
Message ID:
01512705
Views:
36
>Frank,
>
>I have made multiple attempts to do this myself, and in the end, it is my opinion the best way to track changes is to use database triggers as opposed to code in the framework. I also believe that mrroring tables (or having a copy of each table for audit purposes) is not desirable. I would have two audit tables (one header that tracks the table name and date/time and one detail table that has the column name with before and after image) that tracks the changes. This way you can track all changes in one place.
>
>Take a look at the following audit solution:
>
>http://www.krell-software.com/omniaudit/
>
>
>You can download and try it out for 30 days. It uses the structure I mention above and you can selectively choose the tables you want to audit. The price is less than $500 for a single user. By the time you research, write, test and implement your own solution, I think you would eventually say the cost is well worth it. It will take you less than a half hour to set up and implement.
>
>I encountered one problem with this, however. And that is the setting the user who made the changes. The company states you can run a stored procedure before saving any data that would set the user name for the audit, but I was never able to find out where in the MM.NET framework code I could run this and have it hold its value (due to the stateless nature of web apps).
>
>
>If you can figure this out (assuming you try this out yourself), please let me know.

Hi Bob,

The user is tracked by the application level and not the business level so one way to do that is to have all business objects created in your Factory rather than directly and have the userID added to a business object property when it is created. This would be a fairly simple implementation to do and would be implemented in one place. The user information can be obtained from the session as MM stores it there when the login occurs.
Timothy
Timothy Bryan
Previous
Reply
Map
View

Click here to load this message in the networking platform