I am neck-deep in Access and VBA coding at work, now that I am back from our annual training conference in Chicago.

I have been wrestling all day with an Access query with a ton of parameters that causes a crash when run via VBA, but works fine when run manually, which no one would ever do.

Here is a wrapper class to hide implementation details in Microsoft Access VBA projects: DAOQueryRunner.cls. DAOTemporaryTableController.cls relies on this.

This VBA class helps you work with temporary tables in Access VBA projects: DAOTemporaryTableController.cls. You may need to do so if you want to join using a subquery as criteria, which Access does not allow.

I decided to make use of GitHub Gists again. My first gist in several years is LoggedInUserName.bas: a VBA module to get logged in user name from the Windows API.

I got to be reminded today just how long VBA takes to run when used inside SQL Queries in Microsoft Access. I wish I could always use SQL Server, which is faster and better in every respect, but in my Company’s distributed environment, it’s always Access.

I am coding VBA and ripping CDs like it’s the year 2000 today.

I’m back to Access database work today. It looks like I will have to do even more Access work for exam procedure automation in the future, because the work will be portable and transferable to our clients that way. It’s kind of a bummer, though, because VBA is terrible. Native Python support in Office can’t come soon enough for me.

It looks like I will be doing some C# coding for work this month. That stuff is more interesting than the database stuff I do, and far more rewarding than the VBA stuff I have to do sometimes. I wish I could use Swift instead, though.

I wonder how many people still have to use VBA for Excel and Access automation at work, like I do. Googling for Office VBA how-tos feels like jumping in a time machine and going back 10 or 20 years. It is disappointing that Microsoft never added C#/.NET support to Office, but it is understandable.