Mad Props!

A few weeks ago we discovered this funky little error starting to pop up around our company when trying to print a Reporting Services report:

After a bit of searching, we discovered the problem. It turns out that the ActiveX control used to enable printing in Reporting Services had some sort of problem with it in earlier versions of SQL Server 2005. I don’t know exactly what the problem is (not signed correctly or something), but it was a problem that should have prevented it from loading in Internet Explorer. However, IE itself also had a security hole that allowed the ActiveX control to load! So up ’til now nobody has had any errors.

Recently a security update was deployed around the company that patched up the security hold in IE, meaning that now the printing ActiveX control won’t load, leading to the error above.

The fix is … well, reasonably simple: Install a later service pack on the SQL Server. We applied SP3 to one of our servers today to fix this very problem.

A few hours later our CFO wandered down into our office and asked why the dates had “changed” on his reports. It turns out that the calendar control used as a date picker for date parameters was changed in SP3! Here’s a before/after shot:

The one on the right definitely looks nicer, but notice that it now starts the week on a Monday, whereas in the previous version it started on a Sunday!

This caused all sorts of consternation among our accounting girls, who do actually run their reports from Sunday to Saturday and had become used to picking dates from one side of the calendar to the other.

I explained to the poor folks that they’d probably have to direct their complaints to one S. Ballmer of Redmond, WA and went about my business. However, half an hour later one of the other accountants came to see me, complaining that he was receiving an error when trying to print: Something, he said, along the lines of “cannot load client print control”!

When I arrived at his desk and watched him run the report, it turned out that he was simply ignoring the prompt to install the newer version of the ActiveX control, which meant it wasn’t being updated and therefore giving him the error. I don’t know how to react to that, because generally I would advise people not to blindly install ActiveX controls when prompted, so really he was doing the right thing.

What’s funny about these little issues is that the explanation behind the “start day of the week” and “ActiveX installation prompt” stories is quite reasonable, but try explaining ActiveX signing issues and fortuitous browser security flaws to an average user! All they know is that someone messed around with their reports today and caused them grief.

I don’t know that there’s a moral to this story, but if nothing else it’s worth noting that the latest SQL Server Reporting Services version starts the week on a Monday!