database with yearly split data

thanx for your reply. so you people actually agree with my archieving mdbs
idea? timing and file name for the "to be archieved" mdb will be given by the
user, thats an easy job.
Here is my approach to the problem solution and I am not satisfied with it.
A module will post all closure enteries, then
1. Create another mdb promting user for a new name
(data (name) will also be added to a table containing names of all the
archieved databases)
2. Structure of the old mdb will be copied.
3. Data of some of the tables (requirted) will also be imported, e.g;
database names data
users data (security passwords)
customer/suppliers data
stock data
jobs data
4. Append closure entries in new database' corresponding tables as first
records (opening entry)
5. Archieve the old database and restart the application
6. On the first form, before the user log in security, user will be prompt to
select the database to work in. (retreive the database names from the
databases table mentioned in 1.)
7. Programmatically create links to the selected mdb.

Some drawbacks do exist in my approach or perhaps i dont know exactly how to
figure the solution.
1. How to append the closure entry as opening entry in the new database?
2. Reporting may not be possible concerning new and old data.
3. You name it...

isnt there any other MUCH BETTER approach to this issue? Is there anyone who
already has done this before, please guide me HOW? if different than above


Klatuu wrote:
>As to getting the closing entries into the current data, that is a matter of
>timing. You have to do your archiving at the proper time in the workflow.
>
>As to accessing archived data, use a naming scheme for your archived mdbs so
>you can programmatically construct a file name based on a user's choices.
>Then you can link to tables in the archive data for reporting purposes. It
>is perfectly normal to link to multiple backends. Just do not use any table
>names that are year specific.
>> I once have thought of making an archive of the .mdbs yearly by closing all
>> enteries, copy structure of the database and some tables with the data such
>[quoted text clipped - 40 lines]
>> >>
>> >> Fred

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-tablesdbdesign/200809/1

Dave (Klatuu) would be the more expert one to answer this.

If you'd like my "armchair" thought, the only time that I actually did this
(on a very very small scale, and with minimal automatic integration with
other "modules" ) vs. using enterprise software to do it, once the dust
settled after the end of the year (i.e. a few weeks into the new year) I had
them balance / reconcile the previous year's GL, copied/archived the GL from
the year being closed into a new little year-specific GL applicaiton and also
to a locked archive, made "January 1st" opening entries, and then wiped out
the GL entries for the year being closed. I did not do this with or "close
out" anything except the GL. After that moment, there could be not GL
postings of any type for (with a date of) the previous year.

sorry Fred, my message was suppose to appear after you, but it is displayed
above your message, please read that.
Regards,

Fred wrote:
>Dave,
>
>GL in anything except the smallest business environment almost inevitably
>needs automated ties with and databasing of A/R/ A/P, and invoicing/order
>transactions. Combined with that, many transactions (e.g. invoicing) must be
>daabased as events. I've never attampteed it, and instead have used
>enterprise software. My comments were more from seeing how enterprises
>software ( which is a database application) appears to handle these things.
>
>You having written these before means that you know to actually do this far
>better than I do.
>
>Sincerely,
>
>Fred

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-tablesdbdesign/200809/1