Clean-up Advice Requested

[Jeff H]

This hospice db I've been working/learning on is coming together nicely and I'm at a stage where I want to clean up a bit before continuing.

It's very clear to me that I should have planned it all out more thoroughly (if that would have been possible), but in developing it I was constantly experimenting, adjusting to what I read in the texts and got from you, and now I've got a lot of garbage objects.

I'm using the Object Dependencies tool, which is very helpful. And I'm trying to go slowly by checking one object at a time, deleting it and its dependents, then trying out what I think are the operations that would be affected. If the db works, I save that copy and start again in my test copy.

I did try to prepare for this clean up by marking objects that I replaced with "xx" in their names, but I'm still afraid I'm going to delete one that has a hidden ripple effect that won't come out until after I've replaced the back up copy.

Is there an efficient methodology to deal with this clean up process, whether the mess I have now or at least a way to prevent so much mess in future projects?

- Jeff

[HansV]

I don't think there is a generic recipe for this.
I'd either give each version of the database that you save a sequential number (e.g. Db0037.accdb), or use the date+time in its name (e.g. Db_20200930_1147.accdb).
You'll end up with lots of files, but you'll be able to go back any number of versions.
At the end, you can remove the superfluous copies (or keep them, storage is cheap).

[Wendell]

Unfortunately there isn't a better method than what you are using, at least in my view, after developing a number of large and complex Access databases. The clean up process does need to be methodical, and it appears you are doing exactly that. The next step is going to the production phase, and my practice has always been to keep a test version of the database to make changes in before you deploy it to the production version. I"ve not followed all of your recent posts, so this may be redundant, but you should plan to split the database into a front-end with links to the tables that are in another back-end database. That lets you have multiple concurrent users and also paves the way for upgrading to a more robust back-end such as SQL Server or mySQL. Hope this helps.

[ChrisGreaves]

Is there an efficient methodology to deal with this clean up process, whether the mess I have now or at least a way to prevent so much mess in future projects?

Hi Jeff.
I have a utility application PROJE which does a lot of cleanup work on VBA project code. It works on VBA Projects, rather that files, and I have used it successfully for years on Word doc/dot and Excel XLS. I can't see why iut couldn't work on an Access MDB.

Amongst other things it will locate unused procedures and unused data declarations and offer to remove them from the project. It also produces a list of all procedures and their characteristics.
Email me if you would like to try a copy.
Cheers
Chris

[Jeff H]

Thanks everybody! All good tips.

1. Enumerated backups: I have done that in the past, but not as methodically as you suggest. Makes sense. On this project I'm only using three: Testing; Working; and Final. Once I feel comfortable at one level I save it to the next level and go back to Testing.

2. Split Database: Yes, the Michael Alexander book discusses splitting and I do want to try that. Once the staff start using it I'll need a way to keeping working while they input data.

3. VBA Utility: That's actually another level of the same clean up issue, and I'd be very interested in trying that app. I'll email you, Chris.