Hey all,

I am interested in archiving a few databases that grow into infinity as time goes on, databases like "orders" for example. The issue I'm having is currently we just make a copy of the database, rename it with the date, and stick it in an "archive" folder.

This works, kind of, but then we have to know which archive records are in if we want to go back and check them, and trying to look for trends and such over the years is obviously hampered.

What I'm wondering is in situations like this, how do you guys handle the need for speed vs. the ability to still conveniently access and use old data? I've been toying with the idea of a "master" file and a "working copy" file, with the master file used for all analysis type work and the working copy holding only recent files, deleting them after several months or a year. Am I making this more complicated than it needs to be? Doing this would mean i'd have to make sure all records in the working copy were kept updated and correct with the ones in the master file, at least as long as the record existed in both files...

Anyway, thanks in advance for any input you might have!

We've found that if proper design techniques are used (searches using relationships instead of finds, etc.) that size has not been much of a speed issue. In most cases, we've just let the files grow. Some things can make this much worse, such as displaying summary fields on layouts when not required or using finds when "Go to Related Record" is a better option.

Your only other option is to import your archived records into an "Archive" copy which holds ALL archived records and eliminates the problem of what file a record in in. The scripted process for doing this has to make EXTENSIVE checks to make sure the process has succeeded before deleting records in the current files.

-bd

hmm, hadn't considered that. so you use self joins to faciliate that sort of deisgn? thanks for the response btw!