Have you ever found it hard to remember a person’s name? Well, its like that also for developers when they work with another developer’s code because the code is written in VBA Visual Basic for Applications part of Microsoft Access container. The VBA code may need to use the name of a field on a form or report or a field from a table. If the name is misspelled the code won’t work, and if there is no consistency with naming, a developer will constantly have to exit the VBA Visual Basic for Applications part of Microsoft Access to find the database object’s name. When there is no naming rules or consistency, a developer never knows if the object that they are referencing in the code was name in the singular or plural, or is named employee, emp, employees, associates, associate, staff, staffmembers, or staff_mem, etc. Even worse, the different variations are used throughout the MS Access database while they all pertain to the same concept. This causes waste in the process of development.

Besides adhering to certain good design practices when I develop a Microsoft Access application, I consider it indispensable that I make myself dispensable. I will take the requirements, design the architecture, create the application object, and program the VBA Visual Basic for Applications code and consider the developers who will follow. After I deploy the solution, the customer should have the option to have me or anyone else make changes or additions in the future.

An important conversation that needs to happen upfront is what the customer wants with respect to naming conventions of the various parts that together make up the application. On one hand, I have seen other people name a table with 37 textual letters, reports named “Report for Teresa”, and queries that have no meaning in their name of “Query11”. On the flip side, in large companies may be a layer of people that will supply the MS Access project with a “View” of data that comes from a legacy enterprise source such as an Oracle or IBM DB2 source. The view is usually joins together many tables and the tables can have long and strange names, so the person providing the view will rename the tables with an alias such a “emp”, “e”, ”loc”, or “L” because short names are harder to misspell or forget.

I find short, descriptive names hard to misspell or forget. Name length, not using spaces between words, the use of upperLower case without spaces, singularity vs. plurality are all important things that will make it easy for the developer who follow the original developer.

Many Microsoft MS Access databases often link to data that resides in an enterprise data source such as a Share Point list, Salesforce, MS Excel, a third-party Human Resource App, or an Oracle or IBM DB2 database. Often the original MS Access developer(s) is nowhere to be found and neither is any project documentation. When an Access developer is in the main part of the code that interacts with the enterprise data there can be a long list of commands that run the queries that process can be a long sequence of objects that delete, append and update. With a little forethought, the queries that process can appear in the Microsoft Access Database navigation pane in the order that they process. This ordering involves a short process name prefix, a middle set of numbers, and a short descriptive suffix. With a little more thought, a separate bit of VBA code can loop through those names and write out the code sequence that is used in the main part of the code. When that happens, all is easy to follow, and there is nothing to look up or misspell, and there is no development process waste.