Yes full-fledged accounting systems present similar challenges -- either you
freeze the chart of accounts or you subject it to tight audit control. I don't
know your data structure but from the little you say I am wondering if the
problem might not lie in the existing application and its data model, which may
not be suitable for the new spec. After all it isn't fatally hard to create a
data structure which accurately represents datetime data variation and supports
date-time queries of any granularity. It may be another instance of a full
rewrite being cheaper & simpler than an upgrade?
P.
--------------
> -The detail of what we need for the effective dating is that each table would
> have a version number, effective start date, effective end date, process
> start date, and a process end date. The idea would be to use associative
> tables to join individual tables. It has been brought up that ALL tables
> would have these fields. This would include any infrastructure tables. I
> don't see why this would be needed.
>
> -One are I see where this would be a problem would be with code tables. We
> would have no foreign keys in the database. If we use these on dropdowns, I
> don't see how it would work.
>
> Any input would be appreciated.
>
> Thanks
>
> ML Roberts
> [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]
