Andrew Couch - Microsoft Access 2010 VBA Programming Inside Out

pour Pamela, ma raison dtre

Microsoft Visual Basic for Applications (VBA) is an exceptional programming language and environment. The language has grown out of a need to have a programming language that would allow more business-focused individuals to write programs, but equally support the programming features that developers look for in a product. The environment is as important as the language because of its unique features, allowing code to be quickly modified while being debugged.

The Access Basic language in early product versions evolved into the VBA language, which provided a cross-product language for the Microsoft Office products. This all coincided with the revolution of an event-driven approach to programming, which was very important, because the emphasis on being a programmer shifted from writing thousands of lines of code to writing snippets of code in response to events. This also led to a change of emphasis from writing large libraries of code to understanding how to manipulate the object models in the environmenta focus which has progressed with .NET, albeit using namespaces instead of object models.

Even with the introduction of object-oriented programming, VBA has kept pace with the expectations of modern programming. The two products that have shaped VBA the most are Microsoft Excel and Microsoft Access; Excel introduced VBA and originally gained VBA programming features in advance of these becoming available within Access.

A significant strength of VBA is that it is universal to the Microsoft Office suite of programs; all the techniques we describe in this book can be applied to varying degrees within the other Office products. A major turning point for these products was the ability through OLE Automation to be able to drive one product from another, and to cut and paste code between the different environments with a minimum amount of change to the code. This was a revolutionary feature introduced with the programming language of Access Basic, conforming to the new VBA standard established in Excel. VBA suddenly provided the long-awaited platform for the simple integration of the Office products and building solutions that could easily exploit the strengths of each component product in the Office suite. The combination of Access and VBA offers an extremely productive environment within which to construct applications.

VBA has often been criticized for its simplicity as a language when compared to languages such as C++ and C#. Quite to the contrary, the big advantage of VBA is that this simplicity leads to more easily maintainable and reliable code, particularly when developed by people with a more business-focused orientation to programming. Looking toward the future, the emphasis in modern programming has moved from the language syntax to the intricacies of understanding the objects that the language manipulates, so the emphasis on the specific syntax of languages is starting to blur.

In the .NET world, the conflict between using VB.NET, which originates from VBA, and C# continues, because even though the objects being manipulated are now common, there are subtle differences between the languages, which means that developers moving from VBA to C# can often feel that they are being led out of their comfort zone, especially when they need to continue to use VBA for other applications.

Access has often been criticized for creating poor performance applications where a prototype turns into a business critical system, propagating a support nightmare for information technology departments, and leading to applications that eat up network bandwidth. It has also been stated that the product is never used for mission-critical applications. The truth is that both Access and Excel are pivotal to many organizations, but the people answering that mission-critical question are often not willing to admit to this because it is perceived as vulnerability. The problem with using Access and Excel is that Rapid Application Development (RAD) can often come to mean final application without recourse to a more structured oversight of what is being developed, and as data volumes and user communities grow, so too the inevitable flaws in not having designed a scalable solution are exposed.

This book details how Access and VBA are not a problem, although their success is often their downfall in the hands of those lacking some direction on how to effectively develop applications. The big problem with Access is that the underlying database engine is extremely efficient and can compensate for a design that normally would not scale. So if you convert your Access database data to be located in Microsoft SQL Server, Microsoft SQL Azure, or Microsoft SharePoint, you might find that the existing application design techniques for searching and displaying data need to be revised. Our advice is to take into account the mantra of Client-Server design, which is to minimize the amount of data being transferred in any operation.

In this book, we would like to make our contribution toward creating a better informed community of developers, and show how to better develop applications with VBA.