Frustrations with Crystal Reports

Whenever I'm asked my opinion of Crystal Reports I always respond the same way: It's an easy to learn, flexible reporting tool that works extremely well 98% of the time; but the other 2% of the time it's a real bear.

Recently, I witnessed CR in all of its bear-ish glory. At one of my clients, we typically export our Crystal Reports to pdf format when rendering reports from web applications (we've found over time that this works much more smoothly than rendering the reports through an ActiveX viewer). The export procedure is made fairly simple using the Crystal .Net objects that ship with most versions of Visual Studio 2003/2005/2008.

We've been successfully exporting our reports to pdf for web applications for the last 3 years or so with no major problems, but recently we began receiving the non-descriptive error of: "Failed to Export the Report". We received this error on every report that we tried to render through our web applications.

The first thing that I checked was to see if I could manually export the report to pdf locally on the web server (which has Crystal Reports 8.5 installed). That worked flawlessly.

After Google-ing for the error message and sifting through many forum posts and responses, I finally saw where someone suggested checking available disk space on the C drive because Crystal creates temporary files on each export and has no built-in procedure for clearing out those temporary files. We had plenty of disk space available, but I did notice a ton of crystal files in our temp directory (c:\Documents and Settings\LOGINID\Local Settings\Temp).

I retried the export functionality after clearing the temp files, and I began receiving another error message: "Dos Error". I guess you really couldn't hope for anything more descriptive than that, huh?

I scratched my head for a few seconds and thought that maybe deleting the temporary files from the temp directory under the user's profile was to blame, and that, perhaps, logging off and back on to the user's profile would resolve any issues there. Bingo. The code began working like a charm again.

So, in the end it was all a matter of clearing out the temporary files cache, but wouldn't you think that would be built into the Crystal framework? Or worst case, you would think that the export would work regardless of the number of temp files in the directory. Oh well, these are the types of things that make Crystal Reports a major headache sometimes.

If anyone knows of a better reporting tools please let me know!

Bad Cookies

Recently, I experienced tremendous frustration while trying to troubleshoot a problem with a user who was trying to access an intranet application which uses cookies to track various information.

The symptoms were as follows:

• User enters web application.
• Page 1 loads and saves user-specific data to a cookie marked to expire one day from now.
• User navigates to Page 2.
• Page 2 loads and tries to pull data from new cookie.
• Cookie doesn't exist; page bombs out and sends user back to Page 1.

After testing the application on multiple other machines with successful results, I concluded that the issue was unique to the one machine. The first thing that popped into my mind was that there must be some type of internet security setting that was causing cookies to be rejected. I've ran into this before, and it's usually easily corrected by modifying the Privacy settings under Internet Explorer - Tools - Options. I reduced the security settings there and was dismayed to see absolutely no change in the behavior of the application.

At this point I turned to Google, and for one of a very few times, it failed me. I decided to give the forums of experts-exchange.com a shot (not to be confused with expert-sexchange.com). I poured my heart out and waited a day hoping for the best, but this one seemed to stump the "experts" too.

By this time, I had exhausted nearly every avenue that I knew of to dig up a solution, and I felt that I had allocated way too much time to this issue. So, I decided to perform a point-in-time restore of Windows XP hoping to whatever demons had crept into the system would be exorcised. When I began the restore process I ran into another curious problem. None of the dates corresponded with the proper days of the week. After a quick head scratch, I checked the system clock, and found that the year had been advanced from 2008 to 2009.

Suddenly it all made sense; the cookies were getting dropped by the client because the expiration date was getting set to what the client perceived to be nearly a year in the past. It turns out that the user had clicked on the calendar to check some date from next year and did not realize that she had actually adjusted the current date to next year. Incidentally, this is not an issue on Vista machines as the calendar is read-only by default (this is one of the few times I'll actually give Vista some props).

So, long story short, if you ever find yourself trying to figure out why cookies seem to be getting dropped for no reason, a good thing to check is the system clock.