
MS Access As A Dev Tool
Access continues to be a highly efficient tool for business database development.
Don't let a broken database ruin your business. We repair broken Access databases, program
custom Microsoft Access databases, convert Excel to Access, and upgrade old Access
databases to the latest version. Call (323) 285-0939 now for a FREE consultation.
The Best Microsoft Access Database Solutions owner, consultant, and principal programmer is Alison Balter - a recognized expert Microsoft Access consultant. Alison is the author of 15 Microsoft Access training books and videos. She is a frequent guest speaker at MS Access conferences and has developed hundreds of applications for businesses of all types.
We know your business data is important; we listen to your concerns, ask questions, and gather information from all stake holders. We discuss your needs and requirements for your database. We find out what you want, why you need various features so we can obtain as much information as possible. Once we have the information we need, we work with you to design the proper database architecture, plus the dashboards, the questions (queries), forms, and reports you need for an excellent database system.
We also create websites designed for speed to display your data accurately, using ASP.NET technology. Fast, secure, and robust, our ASP.NET web sites and web applications give you true business tool for finding and displaying information dynamically on the web.
Access continues to be a highly efficient tool for business database development.
How to create a Microsoft Access application with some unique tips and tricks.
Your Access developer near me has some great info for you about using Access efficiently.
Call MS Access Solutions at (323) 285-0939 for your FREE consultation.
The material below originally appeared in Alison Balter's book Mastering Microsoft Office Access 2007 Development and is reprinted here with the author's permission. There may be references to "Figures" or "Chapters" that are not reprintable and are not used on this page.
The naming conventions for table names are similar to those for field names, except that the standard for table names is that they should begin with the tag tbl. Chapter 1, "Access as a Development Tool," and Appendix A, "Naming Conventions," (available for download at www.samspublishing.com) cover the details of naming conventions.
Field names can be up to 64 characters long. For practical reasons, you should try to limit them to 10–15 characters—enough to describe the field without making the name difficult to type.
Field names can include any combination of letters, numbers, spaces, and other characters, excluding periods, exclamation points, accents, and brackets. I recommend that you stick to letters. Spaces in field names can be inconvenient when you're building queries, modules, and other database objects. Don't be concerned that your users will see the field names without the spaces. The Caption property of a field, discussed later in this chapter, allows you to designate the text that Access displays for your users.
Field names cannot begin with leading spaces. As mentioned, field names shouldn't contain spaces, so this convention shouldn't be a problem. Field names also cannot include ASCII control characters (ASCII values 0 through 31).
Try not to duplicate property names, keywords, function names, or the names of other Access objects when naming your fields. Although your code might work in some circumstances, you'll get unpredictable results in others.
To make a potential move to the client/server platform as painless as possible, you should be aware that not all field types are supported by every back-end database. Furthermore, most back-end databases impose stricter limits than Access does on the length of field names and the characters that are valid in field names. To reduce the number of problems you'll encounter if you migrate your tables to a back-end database server, you should consider these issues when you're naming the fields in your Access tables.
Adding descriptions to your table, query, form, report, macro, and module objects goes a long way toward making your application self-documenting. This information helps you, or anyone who modifies your application, to perform any required maintenance on the application's objects. Chapter 29, "Documenting Your Application," covers the details of documenting your application.
It is important to be aware how the field names you select affect the potential for upsizing your tables to a client/server database. Database servers often have much more stringent rules than Access does regarding the naming of fields. For example, most back ends do not allow spaces in field names. Furthermore, most back ends limit the length of object names to 30 characters or fewer. If you create Access field names that cannot be upsized and later need to move your data to a back-end database server, you will increase the amount of work involved in the upsizing process. The reason is that you must modify any queries, forms, reports, macros, and modules that use the invalid field names to reference the new field names when you move your tables to a back-end database server.
The precediing information originally appeared in Alison Balter's book Mastering Microsoft Office Access 2007 Development and is reprinted here with the author's permission.
More Access programmer information is available on the Microsoft Access Programmer Oakland, California web page.