This month, Doug Steele looks at how to have larger checkboxes and how to deal with code that gets unlinked from the control to which it’s supposed to be linked.
This Part 2 of Access Answers for Mar 2004
Sometimes the events associated with controls on my form get “unlinked” from the controls. For example, I’ll have a button named cmdProcess and a routine in my code Private Sub cmdProcess_OnClick(), but clicking on the button doesn’t invoke the code. What can I do?
We all love Access, but our favorite tool has many “features” that lead the naive developer into error. You may not appreciate the cost of these less-than-helpful additions but, should you upgrade to an enterprise database, you’ll regret every one of them. Garry Robinson outlines those errors and how to avoid them (along with some code to find the errors).
Recently I was asked to start preparing one of the Access databases that my company provides support for so that it was ready to upgrade to SQL Server 2000 or another enterprise database. The database was initially designed by a techno-savvy person, who, to his credit, came up with a database design that has stood the test of time and the critique of many of his peers. Unfortunately, Access can be a little too accommodating when an enthusiast designs a database, and this can allow design flaws to creep in–errors that a database professional may have been wise enough to avoid.
You’re probably doing too much work–you should be taking advantage of your DBMS’s facilities to get more done in less time. Andrew Wrigley discusses how the principles of declarative design, cascading, and overriding let you have Jet, SQL Server do more work for you.
Access developers often plunge in and, if they ignore the chorus of fearful angels, the inevitable result is a Greek tragedy–a database that requires ever increasing amounts of code in order to work effectively. Every project is different, but the basic guidelines are written in stone: Don’t spend time fighting and/or duplicating what Access is designed to do for you. Instead, invest in learning how to get the most out of Access. The secret of good Access database design is to only add or override what you absolutely have to. Anything else is fudge.
In a second article on the normal forms of a relational database, Peter Vogel discusses forms two through four and offers some advice in dealing with management.
One of the reasons I’m taking the time to look at the various normalized forms for databases is to fight a battle I lost a number of years ago. At the time, I was working on a system that had the keen interest of one of the members of upper management. This president had played around with computers to the point where he felt he knew the essentials of good database design. And, to be fair, he did know some of them. However, he didn’t know enough to appreciate the absolute necessity of normalizing data. As I normalized the original database design and the number of tables increased, he would step in and “de-normalize” the design for efficiency’s sake.
In the first of two articles, Peter provides the essential background on normalization. In this article, Peter looks at first normal form and provides a different perspective on primary keys. More importantly, here’s why you should care about first normal form.
Up here in Canada we have a singer-songwriter named Bruce Cockburn. One of his songs has a chorus that goes, “The trouble with normal is/It always gets worse.” Many people feel that way about normalization. The process of normalizing your database isn’t a theoretical issue: Non-normalized databases cost more to build, run, and maintain than normalized databases. And, as I’ll demonstrate later in this article, in non-normalized databases, some activities are practically impossible. Yet it’s an unusual project where someone doesn’t declare that the data should be “de-normalized” for some reason.