Quickent way to analyze an ACCESS database
I have a client that needs some changes to a database. They have a restricted budget and I need to get this all done in two weeks. However, the database has had at least five other developers working on it and from what I can tell, each basically re-wrote the database but kept all the legacy stuff from the prior developer! This is a mess but what would be the quickest way to analyzed so I can distill down to what is actually being used other than going over each object and see what happens? I tried using the documentor, but the forms output had over 2000 pages!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
What Dale has posted should answer your question here.
A few more notes...
No product may be able to do this with 100% accuracy.
There may be some objects that are "rarely" used, ...not really "orphaned/not needed"
The same goes for code, ..there may be an old function lurking somewhere in a rarely used module...
In may not be "referenced" anywhere else, ...but it might just be use to get a quick result in the immediate window:
?GetSomeValue(argument1, argument2)
There may also be objects that each of these developers liked to use for some reason/purpose.
Then concern here is that if you could start deleting things that some program says are not "actually being used", then you run the risk of deleting something that very well may be needed.
You may not notice it right away, ...but days/ weeks or months from now, one of these developers will ask about it, or some rarely used functionality fails.
So unless you are creating incremental backups and holding them forever, ...you always run that risk.
If it were me, I wold run the utilities/reports and present the results to the governing body.
I would stop short of recommending what objects to delete.
Too many cooks in the kitchen,
Finally it is not clear what your role is here in all of this?
New Head Chef, ...or just another cook...?
;-)
JeffCoachman
A few more notes...
No product may be able to do this with 100% accuracy.
There may be some objects that are "rarely" used, ...not really "orphaned/not needed"
The same goes for code, ..there may be an old function lurking somewhere in a rarely used module...
In may not be "referenced" anywhere else, ...but it might just be use to get a quick result in the immediate window:
?GetSomeValue(argument1, argument2)
There may also be objects that each of these developers liked to use for some reason/purpose.
Then concern here is that if you could start deleting things that some program says are not "actually being used", then you run the risk of deleting something that very well may be needed.
You may not notice it right away, ...but days/ weeks or months from now, one of these developers will ask about it, or some rarely used functionality fails.
So unless you are creating incremental backups and holding them forever, ...you always run that risk.
If it were me, I wold run the utilities/reports and present the results to the governing body.
I would stop short of recommending what objects to delete.
the database has had at least five other developers working on it and from what I can tell, each basically re-wrote the database but kept all the legacy stuff from the prior developer!To me, this would be a good candidate for a complete re-design, from scratch.
Too many cooks in the kitchen,
Finally it is not clear what your role is here in all of this?
New Head Chef, ...or just another cook...?
;-)
JeffCoachman
ASKER
Sandra