Chapter 8: Managing the Application Life Cycle


When you complete an application and deliver it to your client, that may not be the end of the road. As an application is put into use, it will need to be tweaked, and as it is used over the years, the client will want to add new features. Additionally, every few years, you (and the client) need to make a decision about whether to upgrade the application to a new version of Office. (For recent Office versions, the decision to upgrade an Access application is a separate decision from the decision to upgrade to the new Office version in general.)

In my experience, if you deliver an application to a client and never hear from him (or her) again, that is a sign that the application is not being used. If it is used, some changes will always be needed.

Modifying an Application

When the client starts using an application, quite often—in fact, typically—some modifications will be needed. Some of the changes may be simply things that weren’t foreseen when the application was planned, but that become evident when it is used (for example, the need to keep some information confidential). Others may be new features that are needed because of new business requirements (for example, the client is now selling to customers outside of the United States, so country data must be stored in the database, or the client wants to generate Word letters to customers, so a Prefix field is needed for customer names). And finally, a new version of Access may offer features that could enhance the application.

It’s a good idea to include a few hours of development time for unforeseen modifications when planning an application, because otherwise the client may balk at paying for them. However, it’s also advisable to be reasonable about making minor changes without charge, especially if you really should have foreseen the need for them. When a client has a brand-new requirement that wasn’t included in the original requirements of the application, this is new work, and of course should be paid for as such. (For more information on dealing with clients on issues related to changes, see the “Client Relations” section later in this chapter.)

Some requirements are so commonly needed that it is worthwhile to anticipate them. While it isn’t a problem to have a few unused fields in a table and form, adding fields later on (and modifying queries, forms, and reports accordingly) can be quite time-consuming. One of these requirements is the division of names into separate fields. Even if the client doesn’t request it, it’s highly advisable to break down names into at least three fields (FirstName, MiddleName, and LastName for European-derived names; other types of names may need different fields) and often two more fields as well (Prefix and Suffix).

A single field holding an entire name (usually first name first) won’t allow you to easily sort by last name or print a report with names arranged last name first. If you have separate fields for the different components of a name, you can rearrange them as needed or just use certain components, such as first names for name badges for a party or last names for locker or helmet labels.

If the application creates Word letters (or might at some point include such a component), then you need five name fields. The prefix (Mr., Dr., Father, and so on) is needed so that letters can be addressed properly, and a separate field for suffix is needed so that the suffix (if any) can be placed in the correct order when printing names last name first. If users have to enter the suffix (Jr., III, Ph.D.) in the LastName field, reports with names arranged last name first will print with very odd formatting, such as:

Yates Ph.D., Dr. Marian Saunders Jr., Mr. Dennis

With suffix information in its own field, you can place the suffix after the middle name when printing names last name first, using a concatenated query expression such as:

LastNameFirst: [LastName] & IIf([Prefix],”, “ & [Prefix],””) & IIf([FirstName], ” “ & [FirstName],””) & IIf([MiddleName],” “ & [MiddleName]) & IIf([Suffix],”, “ & [Suffix],””)

to print these names correctly:

Yates, Dr. Marian, Ph.D. Saunders, Mr. Dennis, Jr.




Expert One-on-One(c) Microsoft Access Application Development
Expert One-on-One Microsoft Access Application Development
ISBN: 0764559044
EAN: 2147483647
Year: 2006
Pages: 124
Authors: Helen Feddema

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net