| Auditing transactions In a multiuser application, it can sometimes be difficult to track who committed a transaction and when. With a minimum of overhead to your application, you can add two columns to your tables that can help you track transaction information. Consider the following.� With the addition of an Audit_User and an Audit_Date column, you can use the system functions of user_name() and getdate() to insert transaction information along with the application row data.� You can build these columns within your table definition, or ALTER the appropriate table(s) by using the following syntax:� ALTER�TABLE�TableX� ADD�Audit_User�VARCHAR(50)�CONSTRAINT�df_1�DEFAULT�USER_NAME() ALTER�TABLE�TableX� ADD�Audit_Date�DATETIME�CONSTRAINT�df_2�DEFAULT�GETDATE() This will create the two columns with the values defaulting to the current user and the system date/time. This information will be carried along with the row data until another user or process updates the row. In this case, you would need to add additional code to your process to reupdate these two columns.� The downside to this technique is that it erases any previous evidence of activity by replacing old data elements with the new username and date. Since the values will be replaced with whomever or whatever "touched" the row last, it will not track all occurrences of modification, only the last. Although this process does not replace a full auditing system for your application, it does provide for a quick-and-easy alternative to gain insight on who or what process last modified a row. For many applications, that may be all the information that you need.� Correction In the April 17, 2001, Perl TechMail, the sample code contained a syntax error. The query statement� SELECT�TOP�5�*�PERCENT�FROM�pubs..authors should have read� SELECT�TOP�5�PERCENT�*�FROM�pubs..authors |