st**********@gmail.com wrote:
I have been asked to begin documenting the ongoing development and
changes to a database that I maintain. Not the entry of data; this
is about the changes to how tables are restructured, and any new (or
changes to existing) queries, forms, all objects.
Has anyone here done this sort of thing before? Does anyone do this
on a regular basis?
Wow. I would HOPE so for anything larger than a trivial database!!!
Otherwise, how do you fix it six months or a year down the road?
Documenting the stuff is a PITA when you have to do it, but it's best
to do it BEFORE and WHILE you do anything, so that you're clear on what
you're trying to do. Saves a LOT of frustration later on.
Finally -- how do you determine the skeleton structure of a database?
If you have relationships defined, you can print the relationships
window, or you can get 3rd party documenting tools.
Certainly, the brute force method is to look at the design of all
queries and all the forms and reports and macros and view all code
thereof. This could be tedious and time consuming at the first
introduction to a large database. Is there an easier way of
tracking, say, the which queries and forms use a specific field?
Macros? Yech! <those should go! Convert to code!>
You can print the SQLs for each query - that's a walk in the park.
Same for recordsource for all forms & reports
Which queries and forms use a specific field... hmm... that's a bit
harder.
You could go through the rowsources for each form and the fields
collection of each query and grab all that. Basically a PITA. Maybe
FMS stuff will do it for you... if you have TONS of this to do, it
might well be worth it. Or try SpeedFerret...
