Wizards are there to do the work behind the scenes and provide a finished product. Builders, on the other hand, are there to guide the developer through a process rather than to do it. We probably use the Query Builder more than any other. It makes creating queries fast and intuitive. In fact, it is so easy, that we teach a lot of clients how to use it and give them a separate database just for working with ad hoc queries. The other builder that most developers would not want to be without is the Expression Builder. This can even be used in conjunction with a wizard.
Combining the use of builders and wizards is a convenient way to gain some tips and learn about writing code.
In addition to Access-specific builders, there are also some that are pretty much universally available in Microsoft Office, such as the Color Builder. There are several other builders that you may benefit from knowing about. The list of builders and what they do is provided in Appendix K.
Once installed, builders can be accessed from the toolbars and shortcut menus. Even though you may not need all of them now, it is often helpful to have them installed from the beginning. In fact, just to use the ODBC (Open Database Connectivity) Connection String Builder requires installing the "Additional Wizards" component. As developers work with more external data sources, the ODBC Connection String Builder will increase its value tenfold.
Most developers are familiar with Smart Tags. They have been used extensively in Word and Excel. So, user awareness can be leveraged as Smart Tags are incorporated into Access applications. They were available in Access 2002, so it is definitely time for them to become more prevalent. In addition to the Smart Tags that ship with Access, more Smart Tags are available on the Internet and you can create your own tags.
As mentioned earlier, it is possible to combine the power of wizards and builders. One example is to use the builder to create a table and then use the Lookup Wizard to set the properties for a look-up field. This is not an endorsement for rampant use of table-level look-up fields. And, that's as far as this discussion will go on table structure. There are entire books dedicated to that subject and there are camps ready to voice an opinion on the right way to manage tables and fields. And, that leads to the discussion of managers.
Was this article helpful?