Daniel Johnson, Jr.

Part of what I do in my current work is produce ad hoc reports. I often am asked about the information in them because it doesn’t appear to match what decision makers had assumed.

The information on the reports is only as good as the raw data that exists in the system, I tell them. If the company no longer do business with a client, for example, and yet the client is still marked active in the system, then the client still gets counted as an active client. The same goes for employees. Active employee count may appear high, but when it comes down to the actual numbers of employees getting paid, the number is much smaller in some cases.

Helping managers and other decision makers understand these truths is one thing that I appreciate doing in my work.

Tags: reports management database daniel+johnson+jr liaison

As the company grows, the need to be able to report on client’s using the 401(k) plan does as well. We are adding clients to additional databases, and that has meant that the 401(k) reporting tool needed to be updated so that the user can identify which clients are participating in the company plan.

Using Microsoft SQL Server Management Studio, I created the additional tables: one for each additional database. Then I added ODBC links to these tables in the 401(k) reporting tool, the desktop application created using Microsoft Access 2003. I have to remind myself that, for each computer using this tool, I have to create the ODBC connection to each database and table. Then I updated the VBA code so that it can recognize and use the new tables as it compiles the information for the reports.

After testing out the changes, everything appeared to be working fine. I contacted the user and updated her version of the tool, refreshing the ODBC links where needed.

The company is now more ready to begin managing the 401(k) program for new clients.

The company didn’t have a process in place to make sure that this one client receives their 401(k) information on a regular basis. I had developed an application last fall for this specific client to produce the information, but there was no one set up specifically to run the application on a regular basis.

I was contacted earlier today to set up this application on several people’s computers. Interestingly enough, everyone could get to the application, since it exists on a networked drive, but, to make things as easily accessible as possible, I prefer to put a shortcut to the application on users’ desktops.

After I finished that, I sent an email to everyone affected, letting them know about the application, and letting them know how to get the report.

About 15 minutes later, I was summoned to a user’s computer because there was a problem with the report details. She was running the report for last week, but the Last Pay Date for several employees was for this week.

As I looked into the program, I realized that all the other details were correct except for this Last Pay Date, which gets updated whenever a payroll is run. I began brainstorming other ways to get the correct date.

One option was to look at the last pay check date for the date range specified, which is from the first of the month to the date the user selects on a form. That would make sure that date for employees who are getting paid this week is the date the user selected.

As I thought about that, I realized I was not finished. What if we run this report a month from now, and an employee had been terminated this month? The client would still want that employee to show up on the list.

I continued brainstorming, and wrote some mock VBA code on my marker board. Satisfied with that, I created a function, tested it out with various scenarios, and eventually came to a solution that will either use the last pay date for the reporting range OR the Last Pay Date field from the other data table.

I generated the report and sent it off to the client service representative, who will then forward it on to the client.

Two hours ago… I got an instant message from our HR Manager. She’s trying to balance out the 401(k) plans for 2005 and was missing information from a client who was put in a database with other clients who only opt to use us to do their payroll. The desktop application I had developed for her was not set up to get this information readily.

She wanted to know if putting together a spreadsheet manually with the information was her only option. I asked her to give me 30 minutes while I investigated what I could do. She told me that, yes, of course, the information was needed “yesterday”.

I made a backup copy of the application and began to see if it was as simple as changing some of the queries. It looked as though that would be the case, so I contacted her and told her I’d be able to get her the information.

When I tried to tweak the queries, I wasn’t able to get them to run appropriately. I decided to scrap the copy I was working on and start over, this time looking at the VBA code that generates the queries at runtime. A couple months ago, I had set the program up so that she could select a single client for which to obtain information. It turned out to be much simpler to revise that one section of code and then run the application as usual.

She said she needed the reports run for all 12 months in 2005, so after generating the files, I zipped them up and e-mailed the zip file – except that MS Outlook doesn’t allow zip files to be sent as attachments. I “masked” the file name by changing the extension to “txt”, and in the body of the message gave instructions to change the extension back after saving it.

I just received an instant message from her, “thank you DAN!!! You are the best”.

What I was able to do in an hour saved her HOURS of time if she’d tried to do it herself. Being a superhero is great.

A little bit more about the corporate 401(k) application, along with a discussion about how our SQL Server databases are set up.

We have clients set up that for different business reasons we’ve put into separate databases. We have a dedicated server for all the individual SQL server databases. As the company continues to grow, we’ve added new databases.

One of the requirements for 401(k) reporting involves looking at participation. When I first developed the application earlier last year, I set it up to define participation as when an employee of a client contributes to the 401(k). I found out that many clients sign a participation agreement often a month or more before any of their employees start contributing. So I needed to change how the program defines participation.

To that end, we decided that it was best to have a single table in each database where we would indicate a client’s participation. That way, we would look at all employees for those clients in those tables.

In order to expose these tables to the user, I needed to set up an ODBC link. I had to do this for each SQL Server database individually so that each 401(k) participation table would be exposed. Access provides this utility through its Linked Table Manager.

One thing I realized in doing this, is that the settings are machine-specific, which means that every machine using the functionality has to be set up individually. After doing this a couple of times, I documented the process for when we’d need to do it again.

So, once I’d established the ODBC links, I developed a form with a tab control. Each tab shows each table, and this makes it really easy for the user to maintain the participation information for the clients in the different databases.

In her own words, “have I told you how happy I am that you are back????” Nice.

All of this makes sense as I’m writing this, but maybe it doesn’t as you’re reading it. Let me know if that’s the case.