NAMING CONVENTIONS FOR DATABASE OBJECTS

In Level Two of LNC, tags are required for the following Access, Jet, and SQL Server database objects:

Level One also recommends that you place tags on every object name, but recognizes that non-developers may prefer to save time, effort, and complexity by leaving tags off objects where the context is obvious while viewing the Database window. Thus, Level One users are required only to place the qry tag on queries to differentiate them from tables in any combined lists, such as the Choose the Table or Query… combo box on form and report wizards. Placing tags on the other objects in the preceding list is optional.

Tags for Database Window Objects

Table D.4 lists the Level One tags for Database window objects. Note that only one tag exists for each object type.

Although Level One is the simplified naming model, it's necessary to provide tags to identify subform and subreport objects specifically. The distinction between objects and subobjects is critical for non-developers who navigate by using the Database window. Because opening subforms and subreports directly from the Database window isn't appropriate, they must be clearly identified and grouped by using tags.

Table D.5 lists the Level Two tags for Database window objects.

The tags for Level Two provide rich detail about the objects and sort objects with similar attributes together. For example, lookup tables and their maintenance forms are often used over and over in multiple applications. The tags tlkp, qlkp, and flkp clearly identify these objects, making it easy for you to import them from an existing database into a new one when using the object list in Access's Import dialog. However, if a particular database doesn't warrant rich detail, you have generic tags to use as well (for example, qry instead of qsel).

In two special cases in Table D.5 (m[obj] and q[obj]), the conventions prescribe a single-character tag added to the front of the full object name (including the tag) of a related object. This situation occurs where the following two criteria are met:

• A macro is created solely for a particular form or report, as in mfrmCust.

• A query is created solely to serve as the record source for one particular form or report, as in qfrmCust.

Tags for Form and Report Control Objects

Table D.6 lists the Level One tags for control objects on forms and reports. These Level One control tags provide no differentiation of control type other than to distinguish labels, which don't interact with the user, from controls that can display or modify data. This level of detail isn't adequate for applications where VBA code will be written behind forms or reports, but can be a convenience with macro-centric applications.

Don't be lulled into thinking that Level One tags are superfluous. Some expressions on forms and reports can't be evaluated when the name of the control is the same as the name of a table field in the object's recordset. For example, if the following expression is used as the control source for a report control that's named Qty in a report whose record source also contains a Qty field, the report displays #Error rather than the proper calculation:

=IIf([Qty]<100,"Low",[Qty])

The situation created here is called a circular reference, where Access doesn't know whether to evaluate [Qty] in your expression as the table field with that name or the control with that name. Giving the report control a name different from the bound field name, such as txtQty, solves the problem.

Tables D.7 and D.8 list the Level Two tags for control objects on forms, reports, and Web pages. (All control tags are three characters long.) A different tag is provided for each control type, both built-in and standard OLE controls. VBA code written behind forms and reports using this convention will reflect a control's type in its event procedure names (for example, cboState_AfterUpdate). The automatic sorting provided by this notation in the Access module design window can be very helpful during development.

^[**] Hyperlink is actually a ComboBox, CommandButton, Image, Label, or Textbox

All control tags are three characters long.

Some conventions try to catalog or create tags for third-party OLE controls. Such an effort is beyond the scope of this appendix—I take responsibility here only for helping you use controls that are part of an Access developer's standard tool set or are created by my company. If you're interested in tags for third-party controls, a starting point is the document “Microsoft Consulting Services Naming Conventions for VB” on the Microsoft Developer Network CD subscription.

Prefixes for Database Objects

The following list describes the database object prefixes and their usage. With the exception of zz for backup copies of objects, these prefixes are Level Two (that is, developer) elements only:

• _ (underscore) Use this prefix for objects that are incomplete and under development. When the Database window is sorted by object name, this prefix sorts objects to the top, where they're immediately recognized as unfinished and unusable. When the object is ready for testing or deployment, remove the underscore. This prefix isn't used with form and report controls.

• zh Use this prefix to denote system objects, which are for use by developers and application code only and should be hidden from users by default. In LNC terms, system objects provide the infrastructure for an application but aren't meant for user interaction. For example, you would use this prefix on a form's hidden text box that's used to compute a value, or on a hidden table that provides message strings to your VBA code.

• zs Use this prefix to denote displayed system objects, which are for use by developers and application code only but should be displayed in the Database window. If the system object should be hidden, use the zh prefix instead.

• zt Use this prefix for temporary objects that are created programmatically. For example, a query written out from VBA code, used in code, and then deleted by the code would have a zt prefix. Any database object labeled with zt showing in the Database window should be deleted before each repair and compact of a database because by definition it's probably left over from an abnormally terminated process that didn't clean up after itself.

• zz This prefix denotes backup copies of objects that you keep in the database window for reference or possible reuse. Items with this prefix should be periodically reviewed to determine their value and deleted if not needed.

Using Menu Macros

Menu macros behave differently than standard macros; as a result, they fall under separate guidelines when creating their names. Menu macros are used either for bar menus or for shortcut menus.

If you use the Menu Builder add-in, your custom menu macros will be assigned names when the builder saves your menu design. You'll have little control over anything but the tag and base name for the primary (bar) menu. If you use the LNC convention of mmnuName for your menu macro, the builder will create an entire tree of macros beginning with the string you enter—for example,

mmnuMain
mmnuMain_File
mmnuMain_File_Export

If you prefer to create and name menus yourself, you can use a similar convention but with more explicit tags. Bar menus should be prefixed with mmbr, submenus (drop down) with mmsb, and shortcut menus with mmct. Detailed tags like this will help greatly when you're selecting from a list of menus to assign to the MenuBar or ShortcutMenuBar property of a form. This convention also sorts menus by type in the Database window. The preceding macro listing, if produced manually rather than with the builder, would look like this:

mmbrMain
mmctMainFile
mmsbMainFile
mmsbMainFileExport

Because any saved submenu macro can be selected as the primary object in a shortcut menu, this convention gives you the flexibility to create component submenus (such as mmsbMainFileExport), which can be called from both multiple bar menus and multiple shortcut menus and thus reused.

Database Object Name Examples

Table D.9 shows examples of database objects, applying the various conventions shown thus far.