I've been doing a little browser automation lately using the WebView (Edge) control in Microsoft Access. I've covered WebView before, but I haven't really gotten too deep into using it for full-blown website automation.

The goal is to automate some repetitive browser tasks without relying on SendKeys. Instead, Access can navigate to a page, look for specific HTML elements, click buttons, fill in fields, wait for things to appear, and generally interact with the page through JavaScript and the DOM.

One of the things I'm currently automating is downloading some information from YouTube, specifically my members list so new signups don't have to wait for me to manually download and import it every business day. I only need this particular process to succeed once a day, so I set up my database to periodically try it automatically. The interesting part is that the automation worked, but it wasn't particularly reliable.

I'd let it run overnight and find that most attempts failed. Maybe one out of every five or six attempts would actually succeed. Technically, that's good enough for what I need. If it tries several times a day and succeeds once, I'm happy. That's still better than having to remember to do it manually every day. But, of course, the programmer in me wanted to know why it was failing.

My suspicion was timing. Modern websites do a ton of stuff asynchronously. Just because you've clicked a button doesn't mean the next element you need is immediately ready. JavaScript might still be running, the page might still be updating, or an element might exist but not quite be ready to interact with yet. So I decided to add a ridiculous amount of logging.

For every step in my automation script, I started dumping everything into a status box: the action name, description, browser action, sort order, parameters, temporary values, and basically anything else that might help me figure out exactly where the process was failing. Then, if an error occurs, the database can email me the contents of that status box so I can see exactly what happened. And here's the funny part. After adding all that logging, I ran the automation again. It worked perfectly.

Of course it did.

There's actually a name for this kind of thing: a Heisenbug. It's a software bug that seems to change or disappear when you try to observe or debug it. The name is a play on the Heisenberg uncertainty principle from physics.

In my case, I have a pretty good theory about what's happening. My logging routine doesn't just write information to the screen. Updating the status box and processing DoEvents introduces a tiny amount of additional time between automation steps. It also gives Windows and the browser an opportunity to process messages. So instead of effectively doing this:

Click -> Check -> Click -> Check

I'm now doing something more like this:

Click -> Log Status -> DoEvents -> Check -> Log Status -> DoEvents -> Click

Those tiny delays may be giving the YouTube interface just enough time to finish whatever it's doing before Access moves on to the next step. In other words, I may have accidentally fixed the timing problem by adding the code that was supposed to help me find the timing problem. That's a Heisenbug.

I'm going to let the automation run overnight with all of the logging enabled and see what happens. If it suddenly becomes much more reliable, that'll be a pretty strong indication that timing was the problem all along. At that point, I can either add some deliberate waits at the appropriate places or simply leave the logging enabled. And honestly, I might just leave it. This isn't a time-critical process. If downloading one CSV file takes a few extra seconds, I couldn't care less. Reliability is much more important than shaving a couple of seconds off the process.

There's also a good lesson here if you're doing any kind of browser automation. Websites don't necessarily behave like traditional desktop applications. You can't always assume that because Step A finished, Step B is immediately ready. Sometimes you need to wait for a specific element, condition, or page state instead of just firing commands at the browser as fast as your code can execute them. And sometimes adding debugging code fixes the bug. Because programming likes to screw with you like that.

If you guys want to see more lessons on automating websites from Microsoft Access without using SendKeys, post a comment down below. I've been doing a lot more with WebView and JavaScript lately, and there's definitely plenty more we could cover.

LLAP
RR