i've read in several places, these boards included, when laying out dbs, or even before you're laying it out, that it's helpful to graph the way you want the information to flow. i think this is a great idea, and to some extent i wish i had done this. i now have 5 files with the smallest at 30 records and the largest at 650 records.

i'm very happy about the way i've designed it/it's designed itself, i'm learning as i go. but now i wish i had documented some things (relationships/match fields/etc) better than i have done.

does anyone have any advice for "back-documenting" a fm db? i would like to improve the way i have things set up, and i am positive there is much room for improvement, but i don't know where to start, and when things start getting 2 or 3 layers deep in relationships and portals, my head starts to spin.

i guess i'm specifically asking for examples of flow charts or diagrams that people use to map out a db prior to/during designing it.

thanks ya'll.

josh

there are several ways a solution structure can be documented. I would suggest you to invent your own way.

Some time ago I was used to write down structure documentation on a plain text file.

Then, as my skills were growing, I've found that following better design rules and naming conventions there were no more need to document.

Now I just write down some notes on a "Developer Notes" layout on my files to document tricky or complex functions.

Anyway, documenting is always a good thing, but requires some time..

There are some audit tools that generate a report on your solution structure. These may help you a lot!

bye