Crystal Reports 8.5 with multi processors

I help support an app written in VB6 that uses Crystal Reports 8.  Recently we started seeing some very weird behavior where when printing a bunch of documents in a row, at some point in the process Crystal would freeze on the “Printing Records” window and just give us a nice white screen.  At this point the only thing to do is kill the process and start over.  Considering the number of documents being printed could range up to 150 or so, and it would freeze after anywhere from 1 to 50 documents, it was rather annoying to kill the program, load it back up, continue printing, repeat ad nauseam.

I dove into the problem and read a lot on how this version of Crystal could give you white screens while in the Visual Studio IDE due to some circular dependencies in the dlls.  I found no problem with that, but kept poking along that line.  We started to realize the problem was only happening on newer machines.  So we had the thought that maybe if we just slowed the processing down it would relieve whatever tensions existed.  So I put in a little sleep time between each document.  That just made the whole thing much slower to get through, and didn’t help the freezing problem at all.

After some recoding and improvement of the process, with no real gains on the freezing front, I was searching for possible differences in the machines that froze versus those that didn’t.  Somehow between the number of articles I’ve read recently on concurrency and threading and the old machines vs. new machines ideas bouncing around in my head, I decided to check how many processors each machine had.  It seemed to me that the problem computers were all newer, dual core processors, while the funcitoning ones (my ancient laptop included) were single core.  There was even an older ex-server unit functioning as someone’s desktop that had two separate processors in it and that one froze up on us too.  So I thought maybe Crystal didn’t handle two processors well.  I tried to set affinity for our application to just a single processor.  That didn’t fix the issue unfortunately.  I was set to take this thing all the way though, so I grabbed one of our test machines and disabled the second core in the BIOS.  I ran the printing process and sure enough, it made it all the way through without freezing once.

Now, this isn’t the best way to get around this problem I’m sure, since who really wants to lose half (or some percentage at least) of their processing power?  But, this problem has really taken it out of me, so searching for a better solution just isn’t in me right now.  For now, it’s disable one core and let them print to their hearts desire.  Any better ideas?

Legacy Reports

Anyone out there still suffering with Crystal Reports 8 or 8.5?  Anyone still using the ocx to generate a report for a client?  What?  I’m the only one.  Damn.  Well, I’ve finally gotten sick of some of the limitations of using an ocx to access reports through an ODBC connection with static DB links inside the report files.  So any time they move, we get to open up every single one and change the location of them.  No longer I say!

With a bunch of digging through files so old no one should need to remember them, I found the solution to migrating away from the ocx/odbc solution and instead accessing the report application class and doing run-time setting of the database links for each report file.  Here are the tricky steps I had to take to make this work.

First I had to change the code to reference the Report Designer Component instead of the Crystal ocx.  Only a decade after this upgrade first happened in the offices of Seagate I might add.  This is explained in the Crystal Reports 8 Developer’s Guide which you may find as a pdf if you look for it.  Then, after digging around in a couple of troubleshooting articles on Business Object’s website, I got the feeling that this version of Crystal didn’t play too well with the native MS SQL driver.  This was one of the two sticking points for me, as I kept trying to use it and kept getting errors when setting the location of the reports in the code.  I switched my test report to using an OLE DB connection and that helped me open connections after setting the location at run time.  The other sticking point was that the Location field of the reports had been populated with a “database”.”owner”.”table” syntax, which works fine, but will prevent you from modifying the location at run time.  If you just remove the database and owner parts of that in the Set Location dialog within the report, you’ll be able to make the changes and connect to your database at run time with no problem.