LBI Error when publishing Crystal Report

Id check for are special characters in formulas. But first, there should be a more verbose error in your application server logs. can you post that?

matt

Thanks for the reply Matthew.  Here's more informatio about the error

Message:	Invalid table number. CR Labor Utilization - Monthly {D4180E43-DEB6-4686-85D6-22DBE5CFB31F}.rpt
Description:	Report Request Failed For: CR Labor Utilization - Monthly.rpt
Additional Text:	Publication Key: (COMPANY\equal to\1)(ACCOUNTING UNIT\equal to\1B0007)(COMPANY\equal to\1)(ACCOUNTING UNIT\equal to\1C0007)(COMPANY\equal to\1)(ACCOUNTING UNIT\equal to\1D0007)(COMPANY\greater than or equal to\1)(ACCOUNTING UNIT\equal to\*)

Can you Verify Database within Crystal, Save and publish?

Hello,

This error message is familar to me. I got this error message when I did not have a field on the report to burst. In my case the field (accounting unit) was embedded in the page header group text. Lbi could not read the field to burt. I added the field accounting unit to the report and the error message went away. I hope this helps you because this one was driving me crazy.

Thanks jrbledsoe - I checked my report to make sure the bursted fields were there. They were in the group header. Just in case, I moved the same fields into the detail and suppressed them, then republished. The report still hits the same problem though. One thing I thought may be the problem - and it still may be - is that my main Crystal table was created with the 'Add Command' in database expert. The fields I burst on are from this table. I don't know if this can cause the problem I'm seeing.

For Matthew, I did verify the database within Crystal - that worked fine. I then republished but I still get the error.

Hi Matthew,

I verified the database within Crystal, saved and republished it.  I still get the same error.  Do you  know if LBI has problems bursting on fields that come from a Crystal 'add command' query?

Not that I know of but also, you are publishing the report new correct? So at this point in the process, bursting shouldnt be a factor.

I can see how it might work differently for command reports; I opted not to use bursting because my client would have had too much maitenence associated with it. Instead, I pass the UserID from LBI into the report through appended record selection on the maintain parameters screen but I couldn't do this for my command reports, I had to instead create a parameter within the command and link that parameter to the UserID within LBI. Matthew certainly knows more than I do about the bursting but depending on whether or not LBI tries to pass in the bursting information pre-query or not, it could be a similar issue - it can't be done pre-query with a command.

just an FYI on this. Thanks to one of our I.T. guys, this problem has been resolved. The issue was the database driver that was in use. Apparently if the report is driven by a sql script (in the command object) you need to use the oracle db driver. We had been asked to use the Microsoft db driver for Oracle and never had a problem - until I developed this Labor Utilization Report. This report is by far the most involved I've written and most of the report's data is supplied by the command object. As I mentioned earlier, I could always run the report in Crystal, but it always failed in LBI. Once we switched the DB driver to Oracle, it worked both in Crystal and LBI.