<< For instance, after an inventory, I go out and update the current on hand qty/previous on hand qty and there is no reason to create an audit file. However, the process is slowed to a crawl because there is an update trigger on the table.
>> Are you making sure to reduce the UPDATEs to affect only the rows in which the on hand/previous quantities are not the same as the values you're updating to? The fewer rows you operate on, the faster things will go. If you update the values to be values already in the row, you'll incur all the trigger overhead for an update that doesn't actually do anything. Do you _ever_ want to audit changes to the fields On Hand and Previous? If not -- if those are never changed by the user, or should never be audited, perhaps you could split them into a separate table with a 1 to 1 relationship to the main table. Put the audit-worthy fields in the main table and the non-audit-worthy fields in the secondary table, and have a trigger only on the main table. (Use different names and create a view joining the two tables together that has the same name as the current table -- this means your reports and much of your code will still work). Finally, you may just have to write your bulk updates as a single-user process that drops the trigger before updating. -- Larry
