How do others create a system to name the different fields and objects? Everywhere I look, they all seem to say the same thing, with ending the name with tble, or frm and others for the kind of object. To me this is not help since what it is in the type is always available to see in both the builder and the navigation pane. It is getting to the point that I am giving up trying to come up with names and just making a key to explain what I used and why and letting it be called like Query 22 for example which is not a good thing, I am just so frustrated. Any suggestions?:banghead:
Nameing system that really works
- Thread starter mskitty
- Start date
Gasman
Enthusiastic Amateur
- Local time
- Today, 05:07
- Joined
- Sep 21, 2011
- Messages
- 16,911
Well I am a beginner, but I try and use the standard control naming txt, cbo, lbl etc for controls? I use prefixes for tables, forms, reports etc
For tables tbl, Forms frm, Reports rpt, Queries qry. With queries I also use D for delete, A for Append, U for Update etc, so qryACustomerAddress appends customer addresses, whilst qryDCustomerAddress deletes them.
Making it up as I go along really.
For tables tbl, Forms frm, Reports rpt, Queries qry. With queries I also use D for delete, A for Append, U for Update etc, so qryACustomerAddress appends customer addresses, whilst qryDCustomerAddress deletes them.
Making it up as I go along really.
No naming system really works.
Most people use frm tbl qry and the like so that you can see in code exactly what is happening. Although it seems pretty pointless when using the builder, if you come back to things at a later date it is helpful.
You can see that you are looking up a company from the companies table (tblcompanies) rather than just from a shorter list generated by a query (qrycompanies).
After that there is no sensible naming convention, just what you feel comfortable with, just using numbers means you have to look up what they are as oppose to, for example, qrycompaniesfirstletter which you can immediately see is a query that can select companies by their first letter.
In truth most people start with good intentions but soon slip away, most of my databases have qrycompanies and then something else is qrycompanies2 but at least it gives me an idea
Most people use frm tbl qry and the like so that you can see in code exactly what is happening. Although it seems pretty pointless when using the builder, if you come back to things at a later date it is helpful.
You can see that you are looking up a company from the companies table (tblcompanies) rather than just from a shorter list generated by a query (qrycompanies).
After that there is no sensible naming convention, just what you feel comfortable with, just using numbers means you have to look up what they are as oppose to, for example, qrycompaniesfirstletter which you can immediately see is a query that can select companies by their first letter.
In truth most people start with good intentions but soon slip away, most of my databases have qrycompanies and then something else is qrycompanies2 but at least it gives me an idea
Frothingslosh
Premier Pale Stale Ale
- Local time
- Today, 00:07
- Joined
- Oct 17, 2012
- Messages
- 3,276
- Local time
- Today, 05:07
- Joined
- Feb 19, 2013
- Messages
- 17,506
whatever suits you. Main rules to comply with are to avoid spaces and non alphanumeric characters, don't use reserved words and keep it short and meaningful.
for me, because I build systems for a wide variety of clients I tend to precede table names with an acronym to indicate what type of data the table contains e.g.
dta - data ('normal' data - e.g. customers, addresses, invoice headers, invoice lines)
lup - lookup (fixed, will never change (in theory), e.g. countries)
dim - dimensional (contains things like conversion factors, rates of exchange, tax rates)
typ - lookup (new types can be added e.g. customer types, invoice types)
con - configuration data
log - logging data
etc
This also has the benefit from my point of view that I can have one form which will handle any table with the same acronym using a combo to select the table and a subform to display the table which cuts down on the number of forms I require.
The same principle can be extended to forms, reports and queries - by having a defined naming convention rule you can add new objects and not have to modify your code at all to make use of it.
Names like query22 are pointless, give it a brief meaningful name and use the properties (right click on name) to put in a description of what it does. If you right click on the option bar at the top of the navigation window and select View By then Details you will see the properties displayed
for me, because I build systems for a wide variety of clients I tend to precede table names with an acronym to indicate what type of data the table contains e.g.
dta - data ('normal' data - e.g. customers, addresses, invoice headers, invoice lines)
lup - lookup (fixed, will never change (in theory), e.g. countries)
dim - dimensional (contains things like conversion factors, rates of exchange, tax rates)
typ - lookup (new types can be added e.g. customer types, invoice types)
con - configuration data
log - logging data
etc
This also has the benefit from my point of view that I can have one form which will handle any table with the same acronym using a combo to select the table and a subform to display the table which cuts down on the number of forms I require.
The same principle can be extended to forms, reports and queries - by having a defined naming convention rule you can add new objects and not have to modify your code at all to make use of it.
Names like query22 are pointless, give it a brief meaningful name and use the properties (right click on name) to put in a description of what it does. If you right click on the option bar at the top of the navigation window and select View By then Details you will see the properties displayed
- Local time
- Yesterday, 23:07
- Joined
- Feb 28, 2001
- Messages
- 30,301
The rule I always use is this: You are going to be doing the work, usually. Set up rules for yourself that you can live with, then follow them. But remember that these are conventional rather than technical rules. Tables don't break if you ignore the conventions now and then. Forms still open. Code still runs. The naming convention isn't for Access - it is for YOU. If you ain't happy, don't use it. If you like it, use it.
