Auditing thoughts...

We've got a client running OnLine for their application. They want to note every time someone changes a field in their application (i.e. who changed what field on which record and what did they change it from). Try as we might to convince that this kind of control is better maintained to a set of procedures and transaction histories, all of our arguments have fallen on deaf ears. They don't seem to care that when someone enters a record with 20 fields in it, that their 'audit trail' table will get 20 rows added to it. We can't seem to convince them that they are going to produce an insane amount of information that they'll probably never be able to use. The idea is when they track down a discrepancy that was due to something being changed, they'll want to know who did it. "We don't have those kind of controls now" they say. Heck, they don't have ANY controls now. I'm just looking for some options to their grand design. The way they've got it set up right now is going to be just absolute madness to the system. There will more time spent logging all of these audit trails then getting work done. If they were using SE, I could rig something up with auditing (maybe), but they're running OnLine, and that's not an option. Of course, I'me hearing from our side "It's their nickel, let them make the call". So, I'm looking for alternative ways of tracking changes made to a database. Preferably something that won't be really overbearing. Any hints will be appreicated. Thanx! Will Hartung (uunet!la4gen!villy - or - me@zipbang.socal.com)