SQL Server data field of type 'Text' truncates on export

[BFAGG]

I am using Crystal Reports 8.5 on a SQL Server 2000 database.

I have a report that displays a field of type 'TEXT'.

The field is set to 'Can Grow' with no limit.

When the report is run in CR 8.5, if the length of the field content means that the text should continue on the next report page, I can see this OK in the report. If I export the report to either RTF or PDF, the field content truncates at the bottom of the page. The top of the following page contains white space where the text should continue. The next record begins in the correct place.

Any clues?

 

[synapsevampire]

Try placing the field into a text object, this was a workaround for Excel in 8.5

There are monthly hot fixes that often address exporting issues, make sure that you apply these:

http://support.crystaldecisions.com/updates/default.asp

-k

http://www.informeddatadecisions.com

kai@informeddatadecisions.com

 

[gregoriw]

Finally found a thread that hits on the same original problem as I am experiencing now. Only thing is that the truncation occurs with the new Crystal Reports 9.

My issue is with a report/form that displays summary info in the top 40% area of the page and the other 60% is devoted to the detail info. The detail info consists of only one (SQL Server 2000) column which happens to be of the datatype TEXT/BLOB/MEMO. The report is then exported to a RTF formatted file.

Problem is that no matter how big or small the contents of the one field is (the data is never formatted the same between company types...everything is pretty much free-form), RTF exporting appears to ALWAYS truncate the last 10% to 15% of the data. I looked at the data in hex and could not find any NULL characters at the position where the missing info is, so I know it has to do with the exporting process itself.

I tried the excellent suggestion of putting the TEXT field into a textbox object but this didn't help either. The same amount of data was missing either in or outside of the textbox. (The only thing it did do was keep all the data together. IE. If one page had more data than would fit in the 60% area of the page, it would first formfeed to the next page and the display the entire textbox. But it was still missing the 15% of information just as it did when no textbox was used.)

I reinstalled the export features of CR 9, saved all CR8 reports to version 9, rebooted several times, and still the exporting process fails. Everything prints fine when I print the report directly from CR 9 but when I view the exported RTF file in Word, the truncation appears. Because I know the problem exists when the data contains either 50 bytes or 5000 bytes, it also doesn't appear to be a problem with the export process trying to figure out where the next page form-feed character belongs and if it needs to carry overflow data to the next page.

It almost seems that the export process doesn't recognize the font size when generating output. While my report uses courier new regular 8 font to present the detail data, the export process looks like it doesn't translate the font size of a blank character correctly. I say this because those areas of the details that appear to have line spacing is completely different size than the report printed from the IDE.

Any help is greatly appreciated.

Thanks,
gregoriw

 

[gregoriw]

PS. Yet the funny thing about the output is that in the actual RTF file itself, the missing data is seen when I view the file in HEX format! So now the mystery deepens. The RTF file does have the issing data embedded inside the mass of bits of bytes. It may be that somehow the RTF language characters or syntax is incorrectly exported from Crystal to the RTF output file.

So what now? Who do we complain to to get RTF exporting fixed!!!! (Bill Gates?) When I open the file in Word 97, the missing data cannot be seen (even though it appears to reside on/in the file itself). But when I view the same RTF document in Word 2000, some of the same missing data (just a few further characters actually) showed up.

So now I'm getting more confused. Could it be the program that I'm using to READ the RTF file with instead of a perceived problem with CR 9? Is there a special version of RTF formatting that should be used to generate these files?

 

[gregoriw]

Hello All...me again,

The latest I've been able to uncover is that there may be a conflict with the version of the "RTF translator DLL" or something like that which interprets/reads the contents of a RTF file into a word processor...in my case, Word 97.

I tried "reading/importing" my RTF test file into two copies of the MS WordPad program (one version 1.0 and the other 4.0) and strangely enough the entire document including the missing data (blindly assuming to have been truncated) appeared intact. So now my suspicions are focusing on something amiss with how the word processor program is interpreting this RTF document or Crystal's RTF export DLL is not using the right RTF specifications.

Browsing through the Microsoft knowledgebase, I came across two versions of RTF specifications - 1.4 and 1.6 . Could there be a situation where perhaps the RTF export DLL is not following the RTF specifications? or using the wrong/old specifications? How else would the output be incorrectly displayed by MS Word but visible by WordPad?

Is there any updates to the RTF DLL for MS Word 97 that might fix this? Does anyone have an idea as to what the official/latest file DLLs are needed in CR 9? (I have installed the latest CR9 service pack 1). I know there is some discussion about ExportModeller and some other necessary DLL files.

Anybody else have an idea what's going on here?

Thanks,
gregoriw

 

[gregoriw]

Nothing like perseverence to fix your own problems, huh?

This is where I am now with this issue. Kept poking around the CR9 IDE and found that the Spacing option in the Format Editor (to format a field's characteristics on the RPT file) had an interesting option in the Paragraph tab.

It by default is set to Multiple. But when I changed it to Exact and set the points to 13, I suddenly started getting those truncated lines of data to appear in my exported RTF file!!!! Seems that the spacing is based on the font of the field's characters somehow. I still think it's magic how it all works, but I was able to get the output I expected to show up and that's all that counts. Now if I only understood how and when to apply this to other data types.

The only thing that concerns me is that if the TEXT/BLOB field contains more data than one page can hold, the output first issues a form feed automatically and starts rendering at the top of the next page, instead of starting on the same page, then issue a page break and finally continuing the remainder of the field's data on this next page. Somewhat annoying especially since I don't have that field checked for "Keep Together". Anybody got any ideas on that?

So what a day of adventure and frustration and relief. I'd be interested to hear from others who may have also uncovered this remote method of fixing this problem or if they know of another method of preparing these TEXT type data fields.

Thanks,
gregoriw