Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / Reports / Printing / October 2005

Tip: Looking for answers? Try searching our database.

Tips on How to Document Report Design?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
r. howell - 21 Oct 2005 15:06 GMT
I have developed what is (for me) a fairly complex report, with a number of
fields that are not visible, but are necessary to the report's functioning,
and some programming On Print and On Formatting.  Depending on the data, the
report looks different.  

I'll be moving on in June.  They should replace me with someone trained in
Access, ideally much better trained than I am.  However, there's a good
likelihood that that may take a year or two.

I'd like to leave behind something that explains how this report works, so
that someone trying to adjust it to changing realities in years to come can
do so, particularly if they are not so well skilled in Access that they can
do better rewriting it from scratch.

I've got comments in the programming, but has someone got some suggestions
about good ways to document what is going on in a report design?

Actually, any tips on how to leave records that explain what is happening in
a database as a whole would be helpful.  An expert will be able to backtrack
it, but how do I tell some future novice what I did?  Which kinds of things
are they likely to need to know?  Probably too broad a question, but maybe
you have a pointer or two you could give me.

Thanks.
Duane Hookom - 21 Oct 2005 15:20 GMT
Just like you can use comments in your code, you can add invisible labels to
your report (or form). I have often created a hidden table with
documentation on tasks, status, dates, names,... You can build reports and
forms to help maintain the documentation table or tables. Try to keep your
documentation objects generic so that you can import them into other
applications.

There are tools like Visual Source Safe that can be used with Access to
track versions and store other documents.

Signature

Duane Hookom
MS Access MVP

>I have developed what is (for me) a fairly complex report, with a number of
> fields that are not visible, but are necessary to the report's
[quoted text clipped - 27 lines]
>
> Thanks.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.