> Why I updated a few SQL triggers from a financial reporting system in 2006!

Programmers see other programmers fuqups and fix them all the time.  You don't get to take too much credit for these things like Dave Garage points out.  This was a far less important system, but a similar story.  I bet many programmers have similar ones.

There was a custom and home-built financial reporting system that a large company required all their divisions use to report their numbers monthly.  It was dog slow during reporting periods (a few days at the end of the month) when I got there and nobody knew why.  It was driving everyone crazy.

After I took a look at it and realized the problem was not code, but database, I quickly figured out that it was a terribly buggy trigger.  The system had audit tables for the main financial tables and when anyone did a transaction against the main tables the trigger would create audit rows.

The database structure of the main tables was basically division_id, schedule_id, line_id, period_id, value.  The audit table was this plus time, user, and a version number.

But in updating the audit table, the dumbass programmer left out part of the key (I can't remember which column or columns) and the trigger was creating thousands of audit records instead of one for each underlying table row that was being updated.

Not only was it causing a performance nightmare, it was rending the audit table useless as it was huge and duplicative.

Which is interesting because they had been using the system for years before I got there.  I asked about this.  The audit tables were a requirement, but nobody had ever looked at them!

I was popular for about a week because of this.