Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
MMNET & Audit Trail
Message
De
03/06/2011 09:03:02
Timothy Bryan
Sharpline Consultants
Conroe, Texas, États-Unis
 
Information générale
Forum:
ASP.NET
Catégorie:
The Mere Mortals .NET Framework
Versions des environnements
Environment:
ASP.NET
Database:
MS SQL Server
Divers
Thread ID:
01512531
Message ID:
01512705
Vues:
37
>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
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform