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.
The ones I commonly use are in bold print.
My Table Naming Conventions...
tblClientProfile
tblVendorProfile
I then use the Table names as prefix values for the field names, ie...
tblClientProfile
cpClientID (Primary Key, Autonumber)
cpFirstName
cpLastName
etc..
tblProjects
pProjectID (Primary Key, Autonumber)
pCompanyName
pAddress
etc...
Design
My Naming Conventions...
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, which will produce an error.
One side effect of using Reserved Words for Field Names...
Code and Description had been used as field names in the 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 tCode and tDescription the Combo Box behaved as expected accepting the values whether typed in or selected from the list.
Code and Description had been used as field names in the 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 tCode and tDescription 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...
The difficult I do immediately, the impossible takes a little bit longer.
| Tips (Main) |
| Home |
| app | Application | g | Public Variable (Global) | qmak | Make Table Query | ||
| b | Boolean (Yes\No) | gra | Graph | qry | Query (or qdf QueryDef) | ||
| bas | (or mod) Module | grl | Group Level | qspt | Pass Thru Query | ||
| bln | Ballon | grp | Group | qtot | Totals Query | ||
| bof | Bound Object Frame | h | Handle to Windows Object | quni | Union Query | ||
| brk | Page Break | hlk | Hyperlink | qxtb | Crosstab Query | ||
| byt | Byte | idx | Index | r | Parameter passed by Reference | ||
| c | Count of some object | img | Image | ref | Reference | ||
| cbo | Combo Box | int | Integer | rel | Relation | ||
| chk | Check Box | lbl | Label | rpt | Report | ||
| cmd | Command Button | lin | Line | rst | (or rs) Recordset | ||
| cnt | Container | lng | Long | s | (or sng) Single | ||
| con | Generic Contants | lst | List Box | scr | Screen | ||
| ctl | Control | m | Private (module) Variable | sec | Section | ||
| cur | Currency | mod | (or bas) Module | sfr | Subform | ||
| db | Database | obj | Object | shp | Rectangle (Shape) | ||
| dbe | Database Engine | ocx | Custom Control | sng | (or s) Single | ||
| dbl | (or db) Double | ole | Object Frame | srp | Subreport | ||
| dcm | DoCmd | opt | Option Button | str | String | ||
| doc | Document | pag | (or pge) Page of Tab Control | tab | Tab Control | ||
| dtm | Date | pge | (or pag) Page of Tab Control | tbl | Table (or tdf TableDef) | ||
| err | Error | prm | Parameter | tdf | TableDef (or tbl Table) | ||
| f | Fixed | prp | Property | tgl | Toggle Button | ||
| fld | Field | prps | Properties | tlkp | Look-up Table | ||
| fmnu | Menu Form | qapp | Append Query | txt | Text Box | ||
| fmsg | Message Form | qdel | Delete Query | usr | User | ||
| fra | Option Group (Frame) | qflt | Filter Query | var | Variant | ||
| frm | Form | qlkp | Look-up Query | wrk | Workspace |
| f | Function |
| s | Subroutines |
Doing this serves two purposes for me...
The first, it insures that I do not use any Reserved Words (for a list see 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 up 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 CamelBack and your field names will be very easy to type and read! (Thanks to Victor R. for the suggested amendment.)
And, just so you're not stuck with just my point of view... Tony Toews Naming Conventions
The first, it insures that I do not use any Reserved Words (for a list see 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 up 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 CamelBack and your field names will be very easy to type and read! (Thanks to Victor R. for the suggested amendment.)
And, just so you're not stuck with just my point of view... Tony Toews Naming Conventions
