Relationship Between Access and Visual Basic
Access 2010 and Visual Basic work as two separate but interlinked products in your Access application. Access handles the storage of the Visual Basic project (both the source code and the compiled code) in your desktop database (.accdb or .mdb) or project (.adp) file, and it calls Visual Basic to manage the editing and execution of your code.
Because Access tightly links your forms and reports with class modules stored in the Visual Basic project, some complex synchronization must happen between the two products. For example, when you open a form module and enter a new event procedure in the Visual Basic Code window, Access must set the appropriate event property to [Event Procedure] so that both the form and the code are correctly linked. Likewise, when you delete all the code in an event procedure, Access must clear the related form or control property. Therefore, when you open a form or report module from the VBE window, you'll notice that Access also opens the related form or report object in the Access window.
When Access first began using Visual Basic (instead of Access Basic) in version 7 (Access for Windows 95), it was possible to end up with a corrupted Visual Basic project or corrupted form or report object if you weren't careful to always compile and save both the code and the form or report definition at the same time when you made changes to either. It was particularly easy to encounter corruption if multiple developers had the database open at the same time. This corruption most often occurred when Access failed to merge a changed module back into the Visual Basic project when the developer saved changes.
Microsoft greatly improved the reliability of this process when it switched in version 9 (Access 2000) to saving the entire Visual Basic project whenever you save a change. However, this change means that two developers can no longer have the same database open and be working in the code at the same time. This also means that your Access file can grow rapidly if you're making frequent changes to the code and saving your changes.
When you are making multiple changes in an Access application, we recommend that you always compile your project when you have finished changing a section of code. (Click Compile on the Debug menu in the VBE.) You should also save all at once multiple objects that you have changed by clicking the Save button in the VBE window and always responding Yes to the Save dialog box message that Access shows you when you have multiple changed objects open.
In this tutorial:
- Visual Basic Fundamentals
- Visual Basic Development Environment
- Visual Basic Editor Window
- Relationship Between Access and Visual Basic
- Visual Basic Debugging Tools
- Working with the Watch Window
- Variables and Constants
- Variable and Constant Scope
- Declaring Constants and Variables
- Dim Statement
- Enum Statement
- Event Statement
- Private Statement
- Public Statement
- Static Statement
- Type Statement
- Collections, Objects, Properties, and Methods
- DAO Architecture
- ADO Architecture
- Referencing Collections, Objects, and Properties
- Use Exclamation Points and Periods
- Assigning an Object Variable-Set Statement
- Object Methods
- Manipulating Complex Data Types Using DAO
- Working with ADO Recordsets
- Functions and Subroutines
- Sub Statement
- Understanding Class Modules
- Property Let
- Property Set
- Controlling the Flow of Statements
- Do...Loop Statement
- For...Next Statement
- For Each...Next Statement
- If...Then...Else Statement
- RaiseEvent Statement
- Stop Statement
- With...End Statement
- Running Macro Actions and Menu Commands
- Executing an Access Command
- Trapping Errors
- Working with 64-Bit Access Visual Basic for Applications
- Using LongPtr Data Types
- Supporting Older Versions of Access
- Using LongLong Data Types