It was a pretty fun project. They sent us sample data in Excel, and I learned enough VBA to write a nice little program in Access. Basically, you click a button to start the import, and it asks you where the Excel file is, sucks the data in, determines what data is duplicate and what data is new, asks you if you want to update existing records, then if you want to add new records, does all of those things, and outputs a form of log letting you know exactly what was done.
Unfortunately, after Rick (the client) had a chance to play with what we sent him, he sent Jim this email:
Looking back on our initial email, I thought we were looking at a loading process from our production database into the Aries database. Both are in Access so it would seem that there should be a way to link the tables with some type of load query. Your current load process is workable for other areas but it would be a huge benefit if the we could do this loading internally within Access.Apparently what he had wanted was an import from one Access database to another, not from Excel into Access. Although this is not a gigantic change, and is in some ways easier to code, it wasn't what I thought we were doing.
And at first I felt quite annoyed with Rick. Why the hell would you send sample data in Excel if you weren't intending to import the data from Excel? I mean, I worked with what I was given. Stupid client!
But, no. This is actually my fault. I mean, I have most of an entire degree in software engineering. I know better than to just go off half-cocked and write a bunch of code without doing even a minimal amount of requirements engineering. (It's probably not appropriate to write up an entire set of requirements for this project, but a simple email to the client clarifying his needs would have been prudent.) It is not the client's job to know how to unambiguously ask for what he wants.
Stupid consultant! ;-)