Wow, I'd be surprised to find a dba who'd approve a design which implements full
change tracking of all columns in all tables. For specific tables though the tradeoff
I know is between simplicity and performance. On the simple end, keep a history copy
of the table requiring full historical audit with its own PK, add a record to it with
every change, and structure queries against it using its copy of the original PK and
the editDate. On the performance end, maintain a table (or tables) of all
tables/columns requiring full historical audit, update them with all changes to
tables being audited, then write a difference engine and custom reports for it. Not
easy but I've seen it done.
Peter Brawley
----------------
[EMAIL PROTECTED] wrote:
> The project I am working on using PB6 and Riverton's HOW, now has run into
> the situation of using effective dating.
>
> The benefit of this effective dating is to allow users to have "as of"
> reporting. The users can get a snapshot of how data existed in a previous
> time period.
>
> Another task that we are attempting to accomplish is "as it should have
> been". The users want to be able to modify information after a period of
> time. The thing with this is that changes could have occured between the
> change and the new modification. This seems near impossible.
>
> If anyone has attempted items such as these, please respond (pro or con). It
> seems that not many people have done this. Feel free to go back channel if
> you like.
>
> Thanks,
>
> MXR
> > [EMAIL PROTECTED] HOSTED BY IIGG, INC. FOR HELP WITH LIST SERVE COMMANDS, ADDRESS
> > A MESSAGE TO [EMAIL PROTECTED] WITH THE FOLLOWING MESSAGE: help pfcsig
> > SEND ALL OTHER INQUIRES TO [EMAIL PROTECTED]
> [EMAIL PROTECTED] HOSTED BY IIGG, INC. FOR HELP WITH LIST SERVE COMMANDS, ADDRESS
> A MESSAGE TO [EMAIL PROTECTED] WITH THE FOLLOWING MESSAGE: help pfcsig
> SEND ALL OTHER INQUIRES TO [EMAIL PROTECTED]
