We have a audit table which tracks the changes in master table by an insert/update trigger. The trigger will copy all new field values in master table to audit table. We have a datetime column in audit table which tracks the time which insert/update happened on master table (getdate()).
We have unique index over primary key and time column. The problem is if more than an update happens almost at the same time on the master table, then it ends in unique key violation.
Is there any datetime type which captures nanosecond level of precision?
We have a audit table which tracks the changes in master table by an
Share
The DB should inherently handle the updates of the same record via ACID. “Cheesing” the audit table with a joint master_table_id / updatetime primary key to prevent “too many updates” in a short period of time is probably not the right approach…especially as performance improves via new hardware…you could have more “legitimate” updates that your pk is preventing.
I hate to ask, but what type of operation are you performing that’s updating the same row, many times, at the sub-millisecond level? Are you updating col2, then col3, then col4 all for the same PK via some JDBC or ADO connection?
Can you batch these “many” updates into 1 stored procedure call via inputs to the stored proc, so you limit your write operations? This would be faster, and provide less churn on the audit trail.