In This Issue
	Tip of the Month Begin at the Beginning Why People Go wrong Recommendation for First Steps Trap of the Month

Begin at the Beginning

I was taking a hike with one of my sons and we were on a trail that we had never hiked before. The first leg of the hike was a challenge with steep, rocky paths and treacherous patches of wet ground; 2 ½ hours of hard climbing. After resting and eating a snack we headed back. There were several forks in the trail and as luck would have it we made one bad decision that took us off in the wrong direction. The further along we got on the hike the more it seemed that things weren't quite right. After we crested a rather steep hill it was clear we had lost the trail. We checked the map and decided we had no idea where we were. We decided to backtrack and eventually found our way to the trail and completed the hike. An analysis of the map showed that although poorly marked, had we paid close attention we would have seen the ambiguity of a certain fork, and carefully made the decision to take a trail knowing that we should be on the lookout for a potential mistake. Even with a map we made a error that cost us several hours. Imagine how hard it would be to take a hike over new terrain without a map.

Why People Go wrong

Many times I've seen people developing database applications by jumping in and starting to make tables, fields, relationships and forms without taking the time to develop a plan of what they're trying to accomplish, or how the data should be arranged. People take this approach because they get immediate gratification. Within 10 or 15 minutes they have tables and are able to get data in and out. However as they go further into development things start going wrong. They take a wrong turn here, they run into a situation that hadn't foreseen there and before you can say Bill Gates the application is being held together with band- aids. A big clue that a database is improperly designed is that the same data appears again and again. Another typical problem that crops up when no plans are made is that a single field is used for more than one purpose. This is an important trap to avoid. Part of any application planning should include analysis of how different pieces of data relate to each other. The techies call this normalization - more about that in a future newsletter. If you attempt to create a database application without sufficient planning you're essentially taking a hike without a map. You might be OK, but you've increased your odds of having problems.

Recommendation for First Steps

As Stephen Covey said in Seven Habits of Highly Effective People, "Start with the end in mind." If you know where you are and where you want to be the intervening step is mapping out how you're going to get from point A to point B. Spend time up front making your plan so that your journey will be smooth and efficient. .

Trap of the Month

Trap of the Month: If you open a form or a report and you get a box asking you to enter a Parameter Value (See Figure 1) you likely have changed a field name and Access no longer recognizes the new field. In this case Access is looking for a field called TimeGatherID in a table called tblTime To fix the problem, open the query (or SQL statement) that the form or report is based on, and you'll get the same prompt. In design view you'll see that one of your fields now has a title on the order of Expr1:YourOldFieldName. Replace this field with the newly renamed field and the immediate problem will go away. Beware of changing field names, even if they are misspelled, if your application works there is no need to change what's working. If you really get unhappy that you've misspelled a field there is a caption property in fields that allow you to show on the screen something different that what is in the table.