What was actually in the requirements and what the business customer thought was in the requirements were at odds. Apparently, a change was discussed, something was put in the requirements, and the business user signed off thinking her changes were implemented in it.
We're implementing a SOx related change, when the question of history comes up. History is part of the SOx requirement, the business user thinks it's in the requirements, and the developers know it isn't and that there is not enough time to put in history properly before the next release.
I mentioned in passing to one of the BAs that i sit next to, that it could be done with a TRIGGER shudder, but it would be a really Bad Idea. The hack is quick and dirty, TRIGGERs are evil, and this is a change log, not a history, which will be treated as a history at some point.
At the next meeting, the BA brought up the idea and it is decided to implement it. I fight with them over pulling in data from other TABLEs too, telling them that the FK should be enough, and duplicating data is bad. Someone gives me a TABLE structure, which adds new SOx COLUMNs, that is, not only do we capture what the change was, we capture who made the change, which, by definition, is the same as the master record's last updated or the next record in the change log. I register my comments, they are all ignored. The TABLE has the words "audit log" in it, and everyone refers to it as a history.
Now i have been asked to write a SQL statement to help the support team pull up the history. I mention that the original idea, seemingly agreed to, was that this hack would allow us to provide the change log on request, but it would not be automated. Further, this is a bug waiting to happen (especially if anything changes) and i strongly recommend against it. I am assured this will only be used by the production support team for now until a history is properly implemented.
I sent off the SQL to whomever. I remind myself (unsuccessfully, i'm sure) to keep my mouth shut.