I wonder how you folks document your applications? I don't mean the 

properties of the objects, or the coding itself. But how it all hangs 

together. The chains from tables via queries to forms/reports. 

Relationships with sub forms, etc.



I find I tend to solve a problem and then just leave it. When I later want 

an enhancement or modification I spend hours analysing what I did first 

time round to see how I did it!



I'm sure there is a better way. Any books/papers available on this 

important subject? Thanks.

> I wonder how you folks document your applications? I don't mean the 

> properties of the objects, or the coding itself. But how it all hangs 

> together. The chains from tables via queries to forms/reports. 

> Relationships with sub forms, etc.

> 

> I find I tend to solve a problem and then just leave it. When I later 

want 

> an enhancement or modification I spend hours analysing what I did first 

> time round to see how I did it!

> 

> I'm sure there is a better way. Any books/papers available on this 

> important subject? Thanks.



You can use flow charting software such as MS Visio to do that.



Maha

Besides using Visio for flowcharting, use Access' Documentor (Tools >

Analyze > Documentor, and/or you can purchase another product from FMS

(www.fmsinc.com) called Total Access Analyzer.  Also, make sure you

thoroughly comment your code.



John Ruff - The Eternal Optimist :-)







-----Original Message-----

From: Clive Astley [mailto:clive.astley@k...] 

Sent: Thursday, December 20, 2001 7:43 AM

To: Access

Subject: [access] Documenting an application





I wonder how you folks document your applications? I don't mean the 

properties of the objects, or the coding itself. But how it all hangs 

together. The chains from tables via queries to forms/reports. 

Relationships with sub forms, etc.



I find I tend to solve a problem and then just leave it. When I later

want 

an enhancement or modification I spend hours analysing what I did first 

time round to see how I did it!



I'm sure there is a better way. Any books/papers available on this 

important subject? Thanks.

Clive,



<< Also, make sure you thoroughly comment your code.



John Ruff - The Eternal Optimist :-) >>



John makes a great point.  Far too many people make two common mistakes in 

code:  1) they don't comment, 2) they use cryptic variable names.



Get into the habit of using comments whenever and wherever you can.  Even 

if the code seems like a no-brainer or you think to yourself, "well, 

DUH... isn't it obvious?", you never know when you'll come back to it 

needing to know why you did it.  Also, someone else may inherit your code 

if you get reassigned.  You don't want that person to be in the dark.



Variable names are important, too.  Access has a nasty habit of picking 

names out for you if you place objects on a form, for example.  If you use 

the toolbox to create a text box, the name it gets by default is "Textbox 

1."  For heaven's sake, don't keep that name!  Give it a name that makes 

sense when you read it.  The same holds true for table field names, table 

names themselves and queries, too, etc.  Access instruction manuals have 

good naming conventions for tables, queries, and form objects.



In that way, when you write code someone can makes heads or tails of it 

even with sparse comments.  Otherwise it could get... RUFF!  (sorry, John)



Greg

Clive,



<< Variable names are important, too.



Greg



Thanks Greg <gr>.  I would also expand on naming variables.  Make sure

you do not use Reserved Words in naming variables.  If you are unsure if

a variable is a reserved word, go to

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q209187.

Q209187 provides a list for Access2K.  Also check out

http://msdn.microsoft.com/library/backgrnd/html/msdn_20naming.htm

"Naming Conventions for Microsoft Access".  I have found that prefixing

tables, forms, reports, modules, macros, user-defined controls and

variables really helps down the road when you have to come back to the

program to make changes/modifications.



John Ruff - The Eternal Optimist :-)