We are running on XI 3.1 with SP4. Since the install of SP4, our heavy publications(900 Enterprise recipients and around 5,000 page webi report in PDF format) increased from 30 minutes run time to 6 hours. We also noticed that when generating a webi report, the queries finish in time, but it takes extra time to show the results, especially if there are grouping sections or breaks involved. Also, it takes much longer to convert a webi report to PDF format. Have you seen this behavior before? Any suggestions on how to get around this issue?

Thanks,
Anton

destination DLL disabled. []: [CrystalEnterprise.Ftp]

Kindly assist me what to do in this issue….

Great news! Thanks for updating us on the work-around. Please let us know if BO releases an LA Fix for this bug.

Best Regards, Julian

How are things?

Just thought I’d pop by and send you an update to our issue. It’s pretty much resolved now, thankfully.

During deployment of SP4, the CRDBXMLServer.jar file sends a duplicate request for any report that runs over 1 minute (for our setup anyway! Not sure if this is applicable SP4 wide!). The intial request (during the 1st minute) goes away, gets the data and sends the data to Oracle. The duplicate request (after the 1 min elapse) then does the EXACT same thing, but doesn’t find the data as the initial request has already retrieved it. This then produces the above error.

As a workaround, we have the SP2 version of this .jar file (not ideal) and everything works ok. BO themselves are looking to see if this can be fixed correctly with SP4.

Thanks for all your help on this.

Cheers,
Lloyd.

Once again, thanks for your reponse.

I will certainly look at those links now and see if we can progress with them, thanks.

I have ran a few tests with Webi reports, and things were fine. However, due to the nature of our reports which uses an XML data provider combined with an Oracle data provider, the result set only gets into Oracle ‘on the fly’. So basically, a user will schedule a report and the XML data provider will populate Oracle with the result set. Our 2nd data provider will then retreive the data supplied via the XML source.

Unfortunatley, it’s not a straightforward solution as we use ETL to initially get the data. So during a WEBI test, we are just pulling the data ALREADY stored in the Oracle table. Hope that makes sense? Our existing solution populates and retreives practically at the same time.

Cheers,
Lloyd.

Here are some thoughts. First take a look at these two postings on Experts Exchange:

Automated reports randomly fail in Crystal Reports Server: “failed to retrieve data from the database”
Failed to retrieve data from database Crystal Reports 11

After reading those I was beginning to suspect that you may need to update the Oracle client/middleware on your server. Perhaps SP2 was more forgiving of or compatible with an older or mismatched (to the database) client version. SP4 might be less compatible or forgiving of such an issue. If nothing else, it is worth a try. It is the same dart that consultants will throw for you if you pay them thousands of Euros.

Please remember that I am not as fluent or experienced with Crystal Reports as I would like to be, so I may not be able to help much here.

Just curious, do scheduled WebI reports with multiple queries have the same issue?

Good Luck, Julian

The error is:

“Failed to retrieve data from the database” – There is no Oracle code, so it’s extremely hard to pin down this generic message.

We seem to have tied the issue down to larger data sets. We can split a “failing” report into say 3 smaller reports and each one is successful, yet running the report as a whole fails. We have retrieved reports on SP2 in excess of 40k rows, now a 9k row reports fails on SP4.

The schedule normally runs for approx 2-3 min, then brings back that failure message.

I have succesfully ran the failing reports locally via Crystal Designer also.

I built a standalone version of SP2 on our Dev enviroment – everything worked. I then rebuilt the environment with SP4 – the failures began.

Thanks for your help, appreciated.

Lloyd.