Microsoft Access Object Naming Conventions

Articles Index

Course Listing

Free Catalog

Request Information

What's New




When you create a database you should have a standard naming convention in mind. Conventions will vary by product, vendor, and most importantly perhaps, your company or organization. What follows is one that is common in the Microsoft Access community.

General Principles

Names should be concise but meaningful. Whenever practical avoid abbreviations. Isn't LastName better than lName or maybe sName(surname)? Believe me this can be very helpful. You won't have to remember later just what arcane abbreviation you chose. On the other hand don't get ridiculous. EmployeeID or EmployeeNo will do just fine. You don't need to write out EmployeeIdentificationNumber.

Do not include any spaces in your names. Use a convention which capitalizes the separate words or separate them by an underscore. Like so:


Yes, Access will accept names with spaces by enclosing them in square brackets. For example: [Last Name]. But this can cause maintenance problems later. You don't want to have problems with a query because it can't recognize you meant the same thing by [Last Name] with two spaces and [Last Name] with one. This won't happen often but when it does it will be at the precise time you are under pressure to get a report out for management. Don't use spaces and you won't have this problem.


Access object names are typically prefixed with three characters that denote the type of object. This makes the type of object easy to spot in the expression builder, etc. What follows are the prefixes by object.


First, give your database a meaningful name which relates to the application. Something like ShopControl or EmployeeBenefits. Not db1.


Table names should be meaningful to the application whenever possible. If for example you are setting up a database for a kennel you may want tables for dogs and breeders, not products and suppliers. An overdone example, perhaps, but I have actually seen this one!

Tables (Cont'd)

Table names should be plural where it makes sense. I.e., employees, customers, products, etc. Many Access people prefix the name with tbl like so: tblEmployees.

Field Names

Use a meaningful name as discussed under general principles. As well you may want to prefix the name to reflect the table that houses it. Example: empFirst_name in an employees table. This convention is used by some database textbook authors but is by no means universal. Make your own decision on this. Note that fields placed in a child table as a foreign key do not take this prefix but retain their original spelling.


Prefix query names with qry as shown below.


If you like add an underscore. (This applies to other object names as well.)



Use frm. Example: frmWorkOrders. Subforms can be be prefixed with the four characters: sfrm. Some people use frmsub.


Use rpt. Example: rptLaborSummary. As with forms, subreports can be prefixed with srpt or rptsub.


Use mcr. Example: mcrCreateLaborHistory.


There is a complete set of conventions for controls, too. You should always name your controls explicitly if you will refer to them in code. It is not very clear what you mean when your VBA code reads text01 * (text12 + text18).

The conventions vary a bit. Some of the most common are: txt for text boxes, cmd for command buttons, cbo for combo boxes. You can view the well known and very detailed Leszynski & Reddick Access Naming Conventions here.

Dan D'Urso
Laguna Niguel, CA 92677
Updated November 2017
articles at dhdurso dot org

HTML Comment Box is loading comments...

Submit the form below to be notified of new articles or other Microsoft Access resources made available...

Receive course announcements and news. Sign Up Today!

Email Marketing by VerticalResponse

Learn more about our Microsoft Access courses..

View Microsoft Access course catalog.

Please send comments and suggestions to at

Copyright 2017 D.H.D'Urso & Associates
Laguna Niguel, Orange County, California

 Articles Index | Close Window | Back | Top