I understand that reserved words should not be used
Besides being reserved words, reserved words are not usually descriptive. for example "Type". "Type of what"? "Number"...number of what? "Date" of what?
At this point in time, you know what the field name means, but what about in 6 months or a year from now? Or a different programmer has to decipher the names.
You have a field named "CorID (contract office represenative)". Do you really want to type that EVERY time you have to use it in code?
I would put "(contract office represenative)" in the Description column of the table. Then the field name would be "CorID". Doesn't mean anything to me and I can't figure out what "Cor" might be. Even in context of the specific table, I can't figure out what it might mean.
I might use "contractRepID".
I see you use the suffix "ID" on PK and FK fields. And looking at the tables in design view, those fields are numbers. Very good. My convention is to use the suffixes "_PK" and "_FK" for primary and foreign keys.
Spaces. Spaces are problematic. While Access allows spaces in object names, they are a real PITA. If you create a dB for your own use, do what you want. But for a professional dB that might at some point (even a 1 in a gazillion gazillion chance) might be converted to a major dB (SQL Server, MySQL, Oracle,etc), no spaces in names is the correct way to go since most major dBs do not allow spaces in object names.
Same goes for using punctuation or special characters (except the underscore). Not allowed in the major RDBMS's. The hash sign ("#") is a date delimiter and hence a reserved word. I see fields named like "Phone #". So a space and a reserved word...... Argrh.
If you do a lot of coding, spaces, punctuation and/or special characters becomes a pain to deal with; using brackets is extra typing. It doesn't pay to spend hours and hours troubleshooting syntax just because there's spaces or other odd characters in the field/table name - or a missing bracket. Do you know how long it can take to find 1 missing bracket??? It may not seem like a big deal, but when you're writing a lot of VBA code (now or in the future), it can save you lots of development/troubleshooting time.
If you need to separate words in the name, use the underscore instead of a space. Or use CamelBack naming convention.
These are the general rules I try to follow: (my conventions)
1. No spaces in any field/table names.
2. Don't start field/table names with numbers to try and order the field, query, for or report names (Access will do all kinds of weird things that are hard to troubleshoot - personal experience. ex: 1TableName or 2MyFieldName or 3_SomeFieldName...etc...Number suffix are ok.)
3. Object names are letters or numbers. NO spaces, punctuation or special characters (exception is the underscore) (see #2)
4. Avoid long field names (such as field names that are 100+ characters long!) I try to keep names between 5 and 10 characters. A good naming convention helps.
5. ALWAYS take the time to use meaningful names for objects. Buttons named "Command1" or "Command127" aren't helpful when trying to troubleshoot errors. I've seen "Combo12", "List33", "Text57", "Query15", "Form22" ....this is just lazy programming. OK for your personal dB, but should NEVER be in a professional (Paid for) dB.
At some point, you or another programmer will most likely need to modify the code. You can make it easy on yourself (or someone else) and save a lot of time by simply naming things properly/easier.
Which of the following is easier to troubleshoot (this is a simple example but image a SQL statement with joins, etc.....):
Code:
strSQL = "Select FirstName, LastName From tblCustomers"
or
Code:
strSQL = "Select [First name], [Last name] From [my customer table]"
No one except programmers should see the object names, so what you name the objects really shouldn't matter to the client.
The client might have some specifications to follow, but IMO, you still need to follow proper programming guidelines. This includes descriptions of the field names in the table that are not obvious/ easy to decipher and lots of comments in the VBA CODE.
While I can decipher most dBs that are posted on the forum, there have been some real winners in the BAD NAMING category.
------------------------------------------------
Database Table and Field Naming Suggestions
http://www.databasejournal.com/featu...uggestions.htm
NAMING CONVENTIONS
http://access.mvps.org/access/genera...om/namconv.htm
The point is: find a naming convention that works for you and stick with it. But be open to change. I have changes parts of my conventions several times.
Windows 7 64bit 
Access 2010 64bit
Reply With Quote
