Is this a genuine bug?

Question

I have a hue arsenal of reports in my organization that I am responsible to keep running.  A very large percentage of these reports were created using CR v8.5. 
What I am noticing is the else an drop down option on these older report, under File --> Report Options, to allow me to automatically convert date-time fields to string fields.  My guess is this was an 8.5 option for once I tell crystal to convert a date-time to a date-time (gee, what a concept) that the drop down boxes disappears and I no longer have the option to go back.  Back to this option in a minute.
I execute this report as is from the designer, I get no problems.  I can run the report and view them as a report or even export to them whatever format my little heart desires: pdf, xls, csv, etc.
We also have a thick client application that makes use of the RDC to execute these reports.  Same results as from the designer.
Now, here in lies the rub.  Remember that drop down option I mentioned a minute ago? When the same report is executed from with the JRC, either when this option or one of the older crystal functions use for obtaining a date/time (ex.  DTSToTimeString ({Pre_Case.START_TIME})[1 to 5]) is encounter, I have so far come across two undesirable results (and from the JRC, I generally export reports to PDF mostly because I haven't figured out how to make the CrystalReportViewer from making re-querying the DB each time I navigate pages). 
1)  I get an error message stating Adobe is missing the Japanese fonts to correctly display the report.  When I say I don't want the Japanese fonts, I get a blank page for a report.  When I do accept and download the fonts, the result does not look even close to what was designed.
2)  I have also seen and gotten the error message stating simply, "failed to export report". 
When I turn off the convert date-time feature and modify all of my date/time formulas appropriately, works like a charm.
Anyone else have an similar experience with this?  Having to comb through each and every report is not quite what I have in mind (mind numbing comes to mind actually).  Any thoughts from anyone?
Victor

Answer 1

Hello Victor,
I've seen similar issues with the JRC, when exporting to PDF, which was caused when the length defined for a database string (varchar) field in the schema (or database metadata) was less than the length of the data itself. 
For example, if there is a varchar(10) field, but the data in one of the records was a string of length greater than 10.
In the CR Designer and RDC, it force-truncates the additional characters to fit within the defined length.
In the JRC, it tries to write out the entire string, but this leads to corruption of characters beyond the defined length (for the above example, it would be for characters beyond index 10). 
Since the current JRC uses indexed characters in PDF, what happens is that the characters are interpreted as Adobe's CJK Asian language pack characters - and so Adobe requests installing the language pack when you try opening the report.
I think something similar is happening in yours - i.e., the deprecated 8.5 feature is causing the JRC to stumble.
I don't know of an immediate workaround, however, are you opening the report in CR XI Release 2 designer, then saving it back (so it upgrades the report to XI R2)?
Sincerely,
Ted Ueda