Access performance vs table field name

I would like to know if the number of characters of an access table field name can have an impact on performance.
If I use as field name, “client_name” instead of  “name”, is it less efficiency

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Dale FyeOwner, Developing Solutions LLCCommented:
In that specific example, the use of [Name] would be less efficient because it is  a reserved word.

Generally, I try to keep my field names to less than 20 characters, more for the amount of time it takes to type the darn thing.  Never use spaces and avoid special characters.
Not likely.

There is however, a human price to pay.  Very long names are just as bad, if not worse, than very short names.  They leave more room for typos and if there is only a slight difference in the characters from one name to another this could cause subtle bugs.  Optimal name size would be less than 15 characters with the most significant characters at the beginning rather than at the end.  Most of us lean toward prefixes because they make sense hierarchically.  But when you open a table or query in datasheet view, all you see are the first few characters and if you have to widen each header to see the column name, you waste a lot of effort each time you view the data this way.  Prefixes also force you to type more characters before intellisense kicks in.  So prefixes are detrimental to ease of use in most cases.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
Less is More ... I keep my field names as short as possible, and put a description (if necessary) in the Description property with more detail on the name

Seriously doubt there is any performance hit in Today's world of fast machines.

Dale ... why would a Reserved Word in brackets be less efficient ?

Acronis True Image 2019 just released!

Create a reliable backup. Make sure you always have dependable copies of your data so you can restore your entire system or individual files.

Karl001Author Commented:
Thanks everybody
Dale FyeOwner, Developing Solutions LLCCommented:

I meant to use NAME, without the bracket;  with the bracket, I would not expect to see any significant difference.


Generally, with DataSheets, I give each of the fields a caption to replace the column name in the datasheet headers.  This allows me to use spaces, special characters and shorten the names where appropriate to make the datasheet more readable.
Thanks.  Up until A2013 (possibly A2010), Access did very bad things with captions so I never used them and I only recently discovered that the issue has been fixed.  I never display raw queries to my clients so it isn't a problem for them.  And it isn't a problem for me because I avoid prefixes and a very long time ago, I adopted a standard set of abbreviations for my own use so I can keep my names as short as possible and not have to struggle with decisions to abbreviate/not abbreviate.  Always abbreviate.  Every application has a set of attributes and many of them are common words.  Try not to abbreviate to the point that someone coming into the app can't read anything without a decoder ring in hand.  But Customer is always Cust.  Vendor is always Vend.  Address is always Addr, Employee is always Emp,  Account is always Acct, etc.
Dale FyeOwner, Developing Solutions LLCCommented:

Do you also use CamelCase for your field names?  I use the same abbreviations, but frequently insert underscores to make the names more readable.
I use CamelCase 99% of the time because it is more efficient for me to type. Having to shift and use the underscore throws me off.  Of course all those years of COBOL where we used the dash as the separator didn't bother me and it's the same key.  But, we used all upper case so there was no shifting at all.  I guess it is the combination of leaving the letters rows AND having to shift.   I only use the underscore if I want to highlight something.    Of course typing CamelCase, you never shift or at least I don't.  I feel sort of like ee cummings.   Intellisense fixes up the case and if it doesn't, it is easy to see you have a typo.  I wonder if Cummings would have used caps if he had intellisense?
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.