Documenting a Database

[T Martin]

I have read a few things about the importance of documenting a database.
How much info would you suggest be docuemented. Every field with properties
in every form, table, query, etc with all the code. Just a list of all
forms, tables, etc with there purpose.

I've created a few databases for my office, but haven't docuemented and I am
looking to get what I have done documented and just looking for suggestions
on how to document.

thanks for your help.

T Martin

 

[Tom Wickerath]

If you can get your boss to spring for a copy of FMS's Total Access Analyzer, not only will you
get great documentation, but you'll probably find several issues in your databases that could be
improved. A single user license will run $ 299. I use this product, and it is well worth the
money.

http://www.fmsinc.com/products/analyzer/index.html


Tom
______________________________________


I have read a few things about the importance of documenting a database.
How much info would you suggest be docuemented. Every field with properties
in every form, table, query, etc with all the code. Just a list of all
forms, tables, etc with there purpose.

I've created a few databases for my office, but haven't docuemented and I am
looking to get what I have done documented and just looking for suggestions
on how to document.

thanks for your help.

T Martin

 

[Todd Shillam]

If you want to fully document your project, especially after the fact, I would recommend FreeMind --it is a mind-mapping program; however, you can output your map in linear (outline) format. This is a nice program whereas you can document topics as they come to mind in whichever order your contemplate whereas the human mind does not frequently think in linear (chronological) order. Moreover, the application is also freeware. I have used FreeMind to document the whole development life cycle for a number of my projects. Here's a link to FreeMind:

http://freemind.sourceforge.net/wiki/index.php/Main_Page

Make sure your table schema is easy to understand--this should be documented via diagram of table relationships, etc. Also, make sure it is clear which queries are bound to which objects--don't make people guess which query goes with which forms and reports.

I would also make sure you print all your events procedures in hardcopy, or export to text format and place the files in a network share along with the application. Make sure your source code is well documented by including comments about each subroutine.

Finally, create a table in each database just for documentation--you should include a date, time, name, and a comment field. Use this table in each database to document changes, updates, etc.

I would also suggest a Viso type diagram for network topology--the diagram should show where the database is stored and the computers connected to the database.


--
Best regards,

Todd Shillam
Information Technology Consultant
Shillam Technology
http://shillamtechnology.point2this.com

I have read a few things about the importance of documenting a database.
How much info would you suggest be docuemented. Every field with properties
in every form, table, query, etc with all the code. Just a list of all
forms, tables, etc with there purpose.

I've created a few databases for my office, but haven't docuemented and I am
looking to get what I have done documented and just looking for suggestions
on how to document.

thanks for your help.

T Martin

 

[T Martin]

Thanks for your suggestions. I will definitely check into these options.
Thanks again for guiding down the right path.