The difficult I do immediately, the impossible takes a little bit longer.

In database development it is a good idea to use some sort of naming conventions similar to the ones listed below by Leszynski/Reddick. Why? Because the next Programmer to come along should not have to try to figure out whether my query is a make table or delete query! They shouldn't have to guess whether the form is a main form or a subform. You do not have to use the one below as long as you implement some sort of naming convention.

The ones I commonly use are in bold print.

byt - Byte
f - Boolean (Yes/No)
dbl - Double
cur - Currency
str - String
stf - String (fixed length)
var - Variant
con - Use to indicate generic constants
cmd - Command Button
qry (or qdf) - Query (and QueryDef)
tbl (or tdf) - Table (and TableDef)
c - Count of some object
h - Handle to a Windows object
r - Parameter passed by reference
g - Public (global) variable, program-level lifetime
m - Private (module) variable, program-level lifetime
s - Local variable, program-level lifetime (static variable)
(none) - Local variable, procedure-level lifetime
bof - Bound Object Frame
chk - Check Box
dcm - DoCmd
bas (or mdl) - Module
opt - Option Button
fra - Option Group (frame)
pge - Page of Tab Control
shp - Rectangle (shape)
scr - Screen
sec - Section
sfr - SubForm
srp - SubReport
tgl - Toggle Button cnx - Connection
err - Error
fld - Field
idx - Index
rel - Relation
usr - User
qxtb - Crosstab Query
qlkp - Lookup Query
qmak - Make Table Query
qspt - Pass Thru Query
fmsg - Message Form
int - Integer
lng - Long
sng - Single
dtm - Date
obj - Object
frm - Form
txt - Text Box
rpt - Report
ctl - Control
lbl - Label
ocx - Custom Control
grl - Group Level
ole - Object Frame
cbo - Combo Box
ctl(s)- Control(s)
img - Image
lin - Line
app - Application
lst - List Box
hlk - Hyperlink
prps - Properties
brk - Page Break
ref - Reference
tab - Tab Control
cnt - Container
dbe - DB Engine
doc - Document
db - Database
prm - Parameter
prp - Property
rst - Recordset
grp - Group
qapp - Append Query
wrk - Workspace
qdel - Delete Query
qflt - Filter Query
fmnu - Menu Form
bln - Balloon
qtot - Totals Query
quni - Union Query
gra - graph
My Table Naming Conventions...


I then use the Table names as prefix values for the field names, ie...

cpClientID (Primary Key)

vpVendorID (Primary Key)

Doing this serves two purposes for me...

The first, it insures that I do not use any Reserved Words (for a complete List see Problem Names and Reserved Words in Access), which Access would not like and I would have to use brackets around, like [Date] and hope Access still didn't object. Access 2007 and Access 2010 gets especially *upset* when faced with a field or table name that uses one of its favorite words.

The second one, when reading my code months or even years down the road I know immediately which table the field comes from.

I also never use spaces or underscores or special characters... Spaces and special characters mean I have to bracket field names and/or table names. Underscores is just one extra character to type. Okay, now you're thinking, what's the big deal? Less typing... when you realize you're going to *type* code and lots of it... Not only is that pesky underline just another character that must be typed in the name, it is not an easy character to type. (Hold down the Shift key, then reach with the little finger, or is it the ring finger, and hope you hit the right key.) Just leave it out, use Camel Back and your field names will be very easy to type and read! (Thanks to Victor R. for the suggested amendment.)

How to use Windows System Colors   (Access 2003 and earlier)
Where are the Options?   (Access 2007 and higher)
Trusted Location   (Access 2007 and higher)
Export Specifications   (Access 2007 and higher)
Import Specifications   (Access 2007 and higher)
Navigation Pane Options  (Access 2007 and higher)


My Naming Conventions...
And, just so you're not stuck with just my point of view...
Object Designers (Access 2007 and higher)
For those of you that use UDF's (User Defined Functions), you may want to consider prefixing those as well...  Or Access could consider your *getSetting()* as its own (GetSetting() a member of Interaction) and produce an error.
f - Functions
s - Subroutines

One side effect of using Reserved Words for Field Names...

User had named the fields in table:


...then placed a Combo Box on the form using the Table with those two fields as the Row Source for the Combo Box.  When typing in the Combo Box it would not accept the value being typed instead giving the error message, "The item you selected is not in the list..." but it was in the list!  This is because Access could not resolve the field names of Code and Description.  Once the field names were changed to t Code and t Description the Combo Box behaved as expected accepting the values whether typed in or selected from the list.

When it comes to Table names I like to use comprehensible names, ie...

Set Subdatasheet to None (Access 2003 and higher)