If you're like most Microsoft Access users and developers, you've created databases with lots of objects. Over time, it's easy to lose track of which objects are still needed. A temporary query or report becomes permanent because you're not sure if it's being used by other objects. Same with macros and VBA code. The annoying thing is that you may waste time maintaining objects and code that's not even being used. I've written a detailed article about the challenges of finding unused objects (you have to first determine where all objects are referenced before identifying unused ones) and one of the main benefits of using Total Access Analyzer. http://www.fmsinc.com/MicrosoftAccess/UnusedObjects/FindingDeleting.html
I’m glad to see this capability as it will undoubtedly make application development much neater and easier. To that end I’d like to see one of FMS’s fine products incorporate a feature that allows us to generate the code needed to create our own custom objects. VBA developers will appreciate a utility that takes the tedious work of coding Let and Get statements, class initialization and termination events, control of attribute visibility via scoping, the implementation of interfaces, object composition & the use of custom collections to implement one-to-many relationships between associated objects, object pooling, and error handling designed especially for object-oriented routines.
One of the reasons we don’t see much OO code in Access applications is that it’s just plain tedious to write all that stuff by hand; as a result, developers aren’t taking advantage of the robust nature and extensibility inherent to OO design for the simple reason that our tools don’t provide the capabilities that could make our job easier…
Hi Charles,
Glad you like the unused object and code analysis features of Total Access Analyzer.
Your suggestion about creating custom objects in VBA is something we’ve considered but found very difficult to implement in a generic manner to satisfy the different needs of developers. And even if we get it right the first time, as soon as the table structure is modified, the code needs to be updated which would be nearly impossible to do automatically without causing other problems. In Total Visual CodeTools, we have some rudimentary features that let you create new properites with the appropriate Let/Get/Set statements including customized error handling and commenting structures, but it’s not based on an underlying table. The Recordset Builder probably comes the closest, but even then, it’s only creating a recordset listing the fields in the data source rather than creating an entire class.