Daniel Johnson, Jr.

I recently shared about my approach in using Eventbrite to manage New Media Cincinnati events I’ve organized. My approach has changed over time, and I suppose it will continue to be tweaked. This post is not about my approach, though. (more…)

Podcast: Play in new window | Download

This post is one of the more esoteric ones where I delve into the geeky details of some of my programming work. I know – it’s really sexy, isn’t it?

I have mentioned the bridge application I developed that helps make payrolls run faster, helping client employees get paid faster, and so forth, using Microsoft Access 2003 with VBA, ADO, Excel, Office, etc.

Some members of the company are starting to migrate to Office 2007, and we can see the entire organization moving there soon. A few weeks ago, I tried opening and running one of the bridge applications in Access 2007, and it bombed horribly, specifically in how I’ve written it to use the Office 11 FileSearch object.

I just found a couple of few documents on MSDN and TechNet that I hope will help understand what is involved in the migration:

• Transitioning Your Existing Access Applications to Access 2007
• Migration Considerations for Access 2007
• Changes in Access 2007
• Office 2007 Object Model Reference
• Migrating a VBA Solution to a Visual Studio Tools for Office Add-In

Okay, to be honest, I picked that last item because it sounds interesting.

Here’s a project I worked on where I learned an important lesson.

The client was a global consumer products company, and the project was to convert an Access 2.0 application to Access 95, which was a conversion from a 16-bit environment to a 32-bit environment. I’m not even going to claim that I understand what all that means, except to say that there were a lot of procedure calls to the Windows Application Programming Interface (API) that needed to be changed over. This application was used to facilitate preparing the company’s profit/loss and balance sheets for all of their business units around the world. Hereafter, I’ll call it the “financial reporting application”.

Where I went wrong was that I didn’t test portions of the program as I converted the code. It demonstrated a skill in programming that I needed to learn, and I learned that lesson the hard way because, once the program was “converted”, i.e., all the code compiled correctly with no errors, there were other application errors that began popping up all over.

I created a tool to help me keep track of all the errors and the steps taken to resolve them and provided the client with daily progress reports.

As I think back on it, I would have done much better if I had taken more time to understand how the program worked in its prior environment and tested the program incrementally as I revised the code.