I’m working in Access today and I noticed that a confirmation dialog box I have set up to ask me as a developer if I really want to send an email was not working. Initially I thought it was because of a flag that was failing to get set, but that wasn’t it. I kept setting various breakpoints and found that it returned from a subroutine before finishing it after hitting an ODBC error with a query against a SQL Server backend. The call was wrapped in a function that simply gets passed the SQL. After finding where the problem was, I have started working to uncover my SQL error, but that’s kind of beside the point. Why didn’t the SQL error get caught by vbWatchdog?

vbWatchdog is a fantastic Access add-in written by Wayne Phillips. It is meant to catch errors without specifying an error handler so that all errors in your code will be handled. I highly recommend purchasing a license for this. It is licensed per developer and can then be utilized in all your projects for debugging. You don’t have to install the add-in on client computers, it is added to your code by the add-in.

I have no idea whether the issue is vbWatchdog, although I’m pretty sure it has more to do with Access in general because the SQL placed into a Query and switched to Design view gets the error message, “Property not found”, which is actually a 3270 error but it doesn’t give me that number unless I click the Help button on the error box (which is not the vbWatchdog dialog, but a simple dialog box apparently coming from my app.

Ah! Wait, vbWatchdog was working and handing the error off to my app although for some reason my app thinks I’m a normal user rather than a developer. Furthermore, after considering that it was a 3270 error I took a closer look at my fields and one of them is a new field named “Left” which because it’s not in brackets, Access thinks it’s a function. And since the SQL statement is getting parsed deep in the belly of the Access internals, it’s likely that the error handling code I have is choking on whatever vbWatchdog is trying to pass it, or perhaps the context of the error is actually outside of the application and therefore silently continuing by stepping out of the subroutine it was in. Yikes! Talk about unexpected behavior.

Well, here’s to not using keywords as field names. Coder beware!

Here’s a link to the awesome vbWatchdog software:
vbWatchdog – Global Error Handler and Tracing utility (everythingaccess.com)