There is a "feature" of Crystal Reports that just refuses to die. Having struggled with this feature at several points in my career over the last 15 years it is quit surprising that I have not found someone to step-up with a real answer. What I have always done is nothing more than a workaround, but it is effective.
To be more precise, the "feature" is the obliteration of a report when Crystal Reports (CR) verifies the database schema and attempts to re-map fields. I don't know what happens under the hood, but if there are schema changes that CR doesn't like then the corresponding fields are kindly removed from the report. Nice... If there's anyone else who has fought this and knows why, feel free to comment.
To date, my major complaint about CR is that it doesn't know where to stop. It tries to be your database instead of accepting data and formatting the report. Yes, I have used the XML-Schema binding approach and while it has made fighting with deployment a log better it still suffers from the same irrational behavior when the schema changes.
(Big side note: I will offer that if the reporting XSDs developed follow closer to the domain model instead of the database directly then the chance of breaking changes would be reduced. Typically, however, I end up with a compromise and have XSDs that are optimized for reporting.)
Let's get back on track. As annoying as it can be to redo a report that took 2 weeks of effort to format to a customer's approval, there is a way I stumbled onto that will keep the report a little safer and it is annoyingly simple: Wrap all fields placed onto the report in a function. Yep, that easy.
Wrapping the database fields does have a minimal performance impact but the benefit is that all you need to do to fix up the report is to fix the formulas to reference the proper columns in the new schema. As an added benefit, changes to the report like applying a different, custom date format (I did mention the struggle with making a customer happy, no?) is also as easy as adjusting the corresponding formula. To be honest, it was having to do exactly that task in the middle of development that switched on the light-bulb for me -- those fields didn't disappear when the schema changed but the were empty.
My love/hate relationship with CR continues. I am aware of other products but switching technologies is infrequently an option. Building your own can be cost-prohibited. When the customer also screams for a tool to build reports against the database you can work with them on procuring a proper development license and, assuming you didn't compile your reports in as resources without coding the from-a-file option into the application, you can give them the flexibility of dropping their reports into a well-known location and away they go. (side note: I would also suggest directing them to an assembly containing the reporting XSDs so they don't need to bind to the database directly which you should have developed to protect your own reports in the first place.)
I hope sharing this may save someone a few hours. I haven't found a good answer even through Google, but I may not be asking the right question. Maybe I'll get lucky and learn something by an enlightening comment. Feel free to educate or commiserate; you have my empathy and support either way.
