Cleaning up a system

ryetee

Registered User.
Local time
Today, 18:38
Joined
Jul 30, 2013
Messages
952
I have inherited another awful system.
There is a lot of redundancy. unsed tables, queries, forms, report. You name it then it's there and not being used.
Some of that is pretty obvious. Others are not.
I'd like to clear all the mess away.

I thought I'd delete suspect looking objects and then compile and see if I got any errors but not sure that's particularly safe.

What's the best approach?
 
Download the V-tools plug in.

Use the Total Search facility to find every reference to the object before you delete it.
 
Make sure you have Track Name AutoCorrect switched OFF.

Rename suspect objects with zzz_ or similar at the beginning of the object name in them then see what breaks. That way you can restore simply.

Edit: And + 1 to Galaxioms suggestion, although if it's a real mess you may find it quicker to rename things than track through all the possible dependants.
 
I agree that V-Tools is very good.
But don't forget the Object Dependencies tool built into Access itself
 
But don't forget the Object Dependencies tool built into Access itself

That tool is OK for simple query, form and report dependencies but doesn't find it in code, SQL RecordSources or RowSources. You only have to miss one place and disaster will ensue.
 
Thanks for the suggestions everyone I'll give them a go...

WIth Name AutoCorrect and slightly off on a tangent, does it actually work now (i access 2016) as I've read it's best switching it off as it's not reliable.
 
I leave NAC on but I don't often change names. When I do make changes I open the affected objects immediately afterwards.

I have use it since A2003. I only once had an issue where it appeared to have confused a table with a field that had the same name in another table. After that I avoided using the same names on fields and table.
 
All good ideas. I would also recommend MZTools for VBA(reasonable cost) and SmartIndenter (free ) -handy utilities.

Your best approach is to BACK UP before making changes; don't delete(rename with XXX or ZZZ - as Minty suggested); double check and confirm usage/non usage before any Deletes (code, variables,etc).

Allen Browne has a number of Tips for MS Access (easily found via Google)

Good luck -we've all been there to some degree.
 
Joel's got a good article on this as well: https://www.joelonsoftware.com/2002/01/23/rub-a-dub-dub/

Not Access specific, but good general concepts all around. Probably worth a read prior to starting to change anything if you're not familiar with it.

Another thing I've found to be helpful is to refactor existing code (decoupling things tends to be most important, IME) prior to actually removing anything. Dead code/objects don't bother me nearly as much as unclean code. I'd rather have clean, dead code than live code that's a mess.

The nice thing with refactoring starting with that approach is that you can start with the features you use, so you know you're only refactoring live code.

Once the codebase itself starts to shape up a bit, it becomes a lot easier to recognize the deeper level issues.
 
Use it alongside, no problem. They're just addins, there's no particular restriction on "can't have X and Y addin at the same time."
 
All good ideas. I would also recommend MZTools for VBA(reasonable cost) and SmartIndenter (free ) -handy utilities.

Your best approach is to BACK UP before making changes; don't delete(rename with XXX or ZZZ - as Minty suggested); double check and confirm usage/non usage before any Deletes (code, variables,etc).

Allen Browne has a number of Tips for MS Access (easily found via Google)

Good luck -we've all been there to some degree.

Yes to the backup!
Not sure about renaming though, I can always import from the backup.
The renamed object could be redundant but used in a redundant query. I'd end up reinstating it and be back at square 1!
 
Personally, I wouldn't worry much about renaming. It's very risky and with legacy/crap projects, there's usually much bigger fish to fry (such as decoupling the code and refactoring things to make it more maintainable).
 
Maybe import everything into a fresh database except for the suspected problems.
 
Just make sure you have NameAutoCorrect turned off. Then you can rename the suspect objects while still leaving them in the app. Then it is pretty easy to get them back. I use "xxx" as a prefix. It drops the things I am not using but am not yet willing to delete to the bottom of the list. Periodically, I just delete them.

Have you looked at Total Access Analyzer from FmsINC.com? It is a pretty good tool and will help you to identify objects that are not used. It also produces lots of useful documentation reports that will make it easier to get your head around an unfamiliar app.
 
Just make sure you have NameAutoCorrect turned off. Then you can rename the suspect objects while still leaving them in the app. Then it is pretty easy to get them back. I use "xxx" as a prefix. It drops the things I am not using but am not yet willing to delete to the bottom of the list. Periodically, I just delete them.

Have you looked at Total Access Analyzer from FmsINC.com? It is a pretty good tool and will help you to identify objects that are not used. It also produces lots of useful documentation reports that will make it easier to get your head around an unfamiliar app.

I'm using the dependency checker which has helped clear a ton of es aitch one tee out!
Just need to see if the app still works! Compiles a treat!
 

Users who are viewing this thread

Back
Top Bottom