|
Best Practices for Microsoft Access Database DevelopmentErrors, Suggestions, and Performance Tips Detected by Total Access AnalyzerTotal Access Analyzer detects over 270 types of errors, suggestions, and performance tips to help you create Microsoft Access applications that have fewer errors, are easier to maintain, run efficiently, and behave the way your users and you expect. Many of these issues are problems we and our customers have experienced over the years. By incorporating such analysis into Total Access Analyzer, we have an automated tool that can helps us adopt the industry's Best Practices for building better Access applications. The analysis is based on the examination of your entire database by looking at each object and its relationship to others. For instance, the only way to suggest a query isn't being used is to document all the places queries are used, and determine the ones left over. The thorough and automated way Total Access Analyzer examines all your objects, controls, properties, and lines of code is impossible to replicate manually. A quick review of the types of issues detected by Total Access Analyzer should show you why so many Access users and developers rely on Total Access Analyzer to help them build and deploy better Access applications. After all, why embarrass yourself and give your users grief by shipping a database that Total Access Analyzer can tell will crash? Errors DetectedThese are serious problems that will most likely cause your Microsoft Access application to crash. When Total Access Analyzer detects these errors, you should examine them carefully and fix them before deploying your database. In fact, many development teams require using Total Access Analyzer as a quality assurance check before deploying any Access application. Reports Set to a Specific PrinterA common and nasty problem. The report is hard-coded to your specific printer and works fine -- on your machine! Move it to another machine and the report fails. Every report should be set to the default printer and respect the user's Windows printer preferences. Modules without Option ExplicitModules without Option Explicit may have undefined variables, misspelled variables, and a variety of other type consistency issues the compiler won't flag. All modules should specify "Option Explicit" so VBA can catch such problems. Modules without Option CompareWhen the Option Compare statement is missing, Option Compare Binary is assumed, which is a case sensitive comparison. By default, Access uses Option Compare Database which respects the sort order of your database and performs case insensitive text comparisons. Since this is so common, it is best to use this, then use the VBA StrComp function with the vbBinaryCompare option when you want case sensitive comparisons.Security HolesUsers defined without passwords are flagged. Broken Code ReferencesEven when your modules compile, there may be broken references to your code. Functions called in queries, form and report property sheets, and macros all escape detection by the compiler. Renaming functions, misspelling function names, or changing the number of parameters will cause a crash when the user invokes them. Total Access Analyzer detects:
Broken Object ReferencesReferences to objects that were deleted or renamed will fail when the user encounters them. These references are "hidden" within your application and very hard to detect. The database may compile fine, but if a form references a table that no longer exists, that's a time-bomb ready to explode. There are many places Access references objects, and Total Access Analyzer documents and verifies them:
Corrupt and Broken ObjectsSometimes objects in Access get corrupted. This is cumbersome to detect in large databases, but Total Access Analyzer finds them easily:
Modules Events Defined by Not RaisedA class defines an event but doesn't raise one. The VBA compiler doesn't care, but you probably would. Functions and Get Statements Don't Return a ValueFunctions and Get Statements should return a value. Functions that are not assigned a return value should generally be defined as Subs instead of Functions. Property Get statements that are not assigned a return value will cause a runtime error when called. Suggestions OfferedSuggestions incorporate our knowledge of Best Practices for creating professional Access applications. Suggestions cover items that will not cause your application to crash or perform poorly, but may make it easier to maintain, support, and appear more polished. For instance, we may note that certain objects or code are unused, but that doesn't mean you have to delete them. Field Data Type and Size InconsistencyOne of the fundamental Best Practices of database design is to use the same field name to represent the same data. Identically named fields should be defined the same way with the same data type and size. Failure to do this could cause data loss as information moves from one table to another. For instance, a FirstName text field should be the same length anywhere it's defined. Similarly, a numeric CustomerID field should be consistent and not an Integer in one table, a Long Integer in another, and a Double in another. Total Access Analyzer examines all the fields in your database, compares identically named fields in multiple tables, and flags the field names that are not identically defined. Here's a sample report from the Field Consistency Analysis. Unused ObjectsEver wonder want to delete an old query but were afraid because you weren't really sure if it was used? Over time, many databases get full of unused objects. By documenting all the places an object is used, Total Access Analyzer can flag the objects that aren't used:
Of course there are limitations to any detection of unused objects. Maybe you reference the object in code in a way that can't be detected, or you simply use a table that isn't referenced anywhere else. The analysis isn't a recommendation to delete the object, but rather information that the object isn't referenced by the other documented objects. Combined with the Search feature, you can quickly find whether the object name is being used by your object properties, macro lines, and VBA code. Of course there are some situations that Total Access Analyzer cannot detect. If the object is used interactively, part of a table driven system where the object name is stored in a table, referenced by variables in code, you'll need to be cautious as a static analysis program like Total Access Analyzer cannot detect those uses. Here is more information on how Total Access Analyzer detects unused objects in Microsoft Access. Unused CodeOver time, you may also accumulate unused code:
Simplify your modules and reduce bloat by getting rid of code you don't need. For unused procedure parameters, the analysis is trickier. You can simply eliminate the variable you pass to the procedure, but maybe the problem is deeper. Maybe the procedure should be doing something with that value and behaving accordingly. Here is more information on how Total Access Analyzer detects unused Microsoft Access VBA code. Unreferenced VariablesWhile unused variables are relatively easy to resolve by eliminating the variable, unreferenced variables can indicate deeper problems. Total Access Analyzer flags variables that are assigned but not used. For instance, you assign a value to X, but never use X. This could either be code you should eliminate, or code you need to fix because you should be using the value. Access Options
* For Access 2007:
* Identical SQL in Queries, Record Sources, and Row SourcesTotal Access Analyzer performs advanced analysis on your SQL strings to see if duplicates exist across your objects. Duplicates are detected even if you have slight differences with spacing, line breaks, etc. Duplicate SQL strings are opportunities to eliminate queries or create a saved query to share across objects. The benefit is the ability to adjust the SQL in one place and have all its dependencies use it. The downside is that a future change for one purpose may trigger a problem elsewhere. Here's a sample report from the Identical SQL Suggestion. Form Design IssuesTotal Access Analyzer detects many things to improve your forms:
There are also form settings which if not set properly give users more options than you may want them to have:
Form Code IssuesTotal Access Analyzer also detects coding issues in forms:
Report Design IssuesTotal Access Analyzer detects many things to improve your reports:
Table Primary Key Issues
Table/Query Design Issues
Module: Code without Error HandlingError handling is critical to professional applications. If code without error handling crashes, your users see the default Access debug dialog. That's not good. Ideally, every procedure traps for errors and handles them gracefully either within itself or by passing it to a global error handler.
If you find your application is riddled with code missing error handling consider our Total Visual CodeTools program and its Code Cleanup feature that can automatically add custom error handling to the procedures and properties that lack it. Module: Avoid Name ConflictsDon't use the same name for variables in the same scope. Variable naming conventions often solve this (e.g. global variables prefixed with a "g", module variables with an "m", etc.). However, if they aren't used, there may be conflicts. Total Access Analyzer flags:
Module: Scoping Procedures and VariablesGood programming scopes objects to just the level they're needed. If something is only used in a procedure, it should be defined there. If it's only used in a module, it shouldn't be global to the entire project. Total Access Analyzer flags scoping issues and asks you to explicitly scope your code to make it easier to manage and minimize conflicts:
Module: Typecast to Specific Data TypeIf variables aren't explicitly defined as a particular type (e.g. As Integer), they are variants which are less efficient and prevents the compiler from catching certain problems.
* Module: Avoid Using Old Access ConstantsConstants that are part of the OldConstants module in the Access library are from Access 95 or earlier. Examples include A_COPY, A_DIALOG, A_FORM, etc. Total Access Analyzer detects these and recommends the "modern" equivalent such as acCopy, acDialog, acForm, etc. * Module: Exit with the Body of a Procedure/PropertyIf an Exit statement (Exit Sub, Exit Function, or Exit Property) exists in the body of a procedure (rather than at the bottom), any code below it is skipped. This can be a problem if the following code is necessary to cleanup things started by the procedure. It's also a problem if the procedure is very complex and the Exit statement is buried in the middle somewhere. Subsequent developers (or yourself) may forget this behavior and spend unnecessary time trying to debug the code. A better way to exit a procedure is to set variables and use IF statements or other conditionals so that the process always exits at the bottom of the procedure. Consistently using this Best Practice makes your work easier to maintain and debug. Other Module Suggestions
VBA Configuration SuggestionsThese options simplify your code writing experience:
Performance TipsPerformance tips are ideas where you may be able to enhance the speed of your application. Certainly, many tips are not relevant because you've already implemented the most efficient solution. Nonetheless it's helpful to consider these ideas or objects that may be made more efficient. Database
Computer
Tables
Queries
Forms
Reports
Macros
Modules
ADP Views
* Added in Total Access Analyzer 2007 |
|
|
Contact Us
l Web questions: Webmaster
l Copyright
© 2008 FMS, Inc. Celebrating 22 Years of Software Excellence |