Version control / Audit

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a project with a monthly update of information from Accounting. Many
tables with relationships...One Table holds the monthly data with the 4
fields required to tie into other tables.

Issue: Historical numbers in accounting can change!!! corrections,
restatements errors all mean that I am loading not incremental information
but all periods so that both systems have same data today.

Question: I want to Audit what is changing between uploads and be able to
refer to diferent versions of the data.
Wondering what is the "best" way.
1) I could add a "version" or "release date" field and keep adding full
history to the same table but the data table would suffer from unnecessary
bloat - most users will only want the most recent release version of history.
2) I could use separate files with just the data table and a version naming
convention and import additional versions when required. (augment most recent
with desired comparison version data then run report.
3) Better Ideas???

With Audit such a big deal these days I hope someone has a simple approach
to this (other than telling accounting to storp rewritting history:). THANKS
 
This is very difficult to make in access - you can only put audit trail code
in forms, but data in tables could be easy changed. so you have to apply
security and allow data modifications only via code. So to make a really
working solution - you have to consider using SQL Server or MSDE
 
Audit Trail is not the question. Where and how to structure the data is the
question.

Let me clarify - the data I get is a dump from ERP (audit trail is their
problem). My system produces graphs of historic data and needs to use most
recent history from ERP. While retaining the ability to access data from
prior month dumps. All dumps are full not incremental. And I need this
granularity for certain analysis:

Best example is comparing this month's data to budget and most recent
forecast. then compare this month's forecat to last month's forecast. Or
tracking changes in forecast over the year. Again a version field would
allow this but the table would get huge very quickly.
 
Hi,
Then i think you have two options. If data you get already have a
timestamp - you can use it, and store only chnaged data. if no - then after
getting a new set you determine what row were changed and modified rows save
you your own time stamp.
One more approach i used once - users made a copy of consolidated data every
month, and then they compared these copies to findout what was changed, and
what performance they had
 
Back
Top