Sybase odbc information exported to Excel screwy?

[ITCPhil]

I am exporting a report to Excel via Crystal Enterprise. This is using CR 8.5 and a Sybase ODBC (gathering data from a Symposium server). The problem is that while it exports properly directly to Excel, if I export using Crystal Enterprise, it is leaving blank 3 blank cells between each row of data.

I've tried checking/unchecking
-Export report header
-Tabular format

and also running it as "Excel (Data only)" but it leaves the same space.

The thing is there are multiple subreports forming one large report and some of the other tables I use to report from work perfectly but this one leaves blank lines. (These are all from the same server).

Any ideas?
Thanks in advance,
Phil

 

[synapsevampire]

I'd guess that your DLLs are out of synch, make sure that you have the same versioning by applying the same service pack version:

http://support.businessobjects.com/fix/samplescr.asp

-k

 

[ITCPhil]

Thanks for posting, that was one answer I was expecting from my searching earlier after posting but it's not for everyone sadly. I work for the governement and they audit all workstations so dll changes would mean wrist slapping and reimaging of my workstation.

Actually, after running the report around 100 times with different settings, I did get it to work when I came back from lunch. The solution was to make the affected subreports as small (thin) as possible so that while nothing of them is legible in Crystal Report, they appear correctly out of Enterprise... I just made them all as small as I could and it worked, go figure.

Still, from Synapsevampire's fix and my (imo really stupid) workaround, maybe someone will benefit in the future.

ITCPhil.

 

[synapsevampire]

Ahhh, I see, I didn't realize that the subreports were for shared variable passing only, you should reference such things as this is a very common issue. The differences should occur in CR and CE, so the DLLs are probably still an issue.

In general try to avoid using subreports.

-k

 

[ITCPhil]

I avoid them as I can but for some reports you have no choice...This one pulls data from 2 odbc sources and 5 different tables that not linked in any way.

 

[synapsevampire]

Yeah, that sounds more like a Dashboard type of report, the alternative might be to create a Stored Procedure to return all of the data depending upon the recordset(s) in use in the report and the layout.

-k