I thought this way before, and looked down on what I had made, but I'm slowly coming around to the idea that its more about how well the approach works and what it teaches you than about the technical details. I definitely wouldn't code it the same way today, but it worked well and taught me a lot. I wouldn't stop anyone who's in a similar position from doing the same.

The problem of course would have been interacting with the second DB considering the fact that it was a "separate program" as the author states. If the program wasn't offering an interface to interact with it outside of the GUI and especially if it wasn't making any network calls upon querying (although hacking network calls could have been quite difficult for a beginner) I am not sure how the process could have been done differently.

Clicking on things is the primary and often only interface that most Windows programs support. And frankly it can be much easier to script some actions with something like Java's Robot class than to dig through the cesspool that is MSDN trying to figure out how to get the same simple things done with the overly-complicated and poorly documented COM interfaces that might or might not exist.

Also, I'm not sure which is more embarrassing, having to write code to interact with the GUI or having to write VBA code.

I cringed too, but then I realized this is probably the best way to start out. It's only a 'problem' because it's a bit more glue code (but less 'figuring things out' time).

The only truly cringey part is not knowing about CSV!