PEStartPrintJob : Error detected by database DLL - Oracle Procedures? 2

[cjmartin]

When attempting to schedule Crystal Reports that use Oracle (PL/SQL) Stored Procedures, I get an error message stating "PEStartPrintJob : Error detected by database DLL". This error message is received regardless of whether report parameters exist or not. I have not read anywhere that the use of Oracle Stored Procedures conflicts with Seagate Info scheduling, but...

Any suggestions/thoughts/opinions/observations? Your input is greatly appreciated!

FYI - I have not noticed similar problems for reports using Oracle Views or database tables. Also, we are running Seagate Info 7.0.2.200 on NT.

 

[BlurredVision]

I run into that problem myself. What happens if you open up the report within the designer that is within info and attempt to run it? For me, at least, it tends to be a missing function of some kind. I write my reports on my local workstation, then copy them over to the info server. Our info server isn't always up todate with our workstations.

Let me know what you find out.

Brian

http://www.crystalinfo.net

 

[RoughingIT]

There is a white paper on the web site - ahem,
Here:

http://support.crystaldecisions.com/communityCS/TechnicalPapers/scr_oracle_stored_procedures.pdf.asp

Make sure that your stored proc is appropriately configured.

 

[cjmartin]

Brian,

I attempted what you suggested (unless you are suggesting I need to be on the Info Server - I am on my workstation) and did not have any problems running the report. To clarify, the report I ran was the one that was saved on the Info APS and failed to run via scheduling in Info.

I believe the Info Server and my workstation were installed at approximately the same time, with no upgrades/patches performed on either (I think). I wouldn't think there would be an inconsistency between the two, but I suppose I can't say for sure.

 

[cjmartin]

RoughingIT,

I have previously viewed this documentation. However, I soon dismissed it as incorrect and/or obsolete when I saw the results I experienced differed from what is documented. For example, it states that Crystal 7 can not report off of Orac Stored Proc for the Oracle 8.1.x. This conflicts with my experience - I have a number of Crytal reports that use Oracle Stored Proc (Oracle 8.1.6). Also, as of yet none of my Stored Proc are using a Package/Ref Cursor. Yet the documentation states that Packages are required for a Crystal report to use a Stored Proc. Now if this documentation was referring to Seagate Info instead of Seagate Crystal Reports, then not only would this documentation ring true to me, it would explain the issue that I originally posted. I see no mention of Info in this documentation, however.

My humility suggests my lack of understanding is what is causing me to misinterpret this documentation. Please feel free to set me straight.

Thanks for your feedback.

 

[RoughingIT]

What you want to narrow down is weather the report itself has an issue or weather Info can't handle it. So try this:
On your Info server, start up the Report designer and open your report from the Info desktop. Refresh it, go to the last page, dig into your subreports and then export it to rpt format. If that works, the the report server has a problem with your report. If it doesn't work and you get an error at any time, then there's something in the database connection setup on the server not right. Above steps are pretty much what the report server is doing when you schedule.
Your client box can be differently configured that the server - down to such invisble details as the MDAC versions. That's why it's always best to test on the server directly.
I suppose that the white paper indicates that Oracle stored procs can best and most reliably when those conditions are met, you might have been lucky so far.
Would it hurt to create a stored proc, something very simple, according to the instructions to test it out?
And justy to make sure you are not running into a rights issue, try once to run the sentinel on the server under your domain account.
Have fun,
;-)

 

[cjmartin]

Unfortunately, physical access to the Info server is no easy task here. I've fought for remote access (at the least), ie VNC Viewer, but to no avail. That's a whole other story though. If I can eventually accomplish this, I will try your suggestions (including simple stored proc test).

Thanks a ton!

 

[synapsevampire]

If you don't follow CR's methods for running SP's, they won't support you, and something will probably break eventually.

I've cheated the connectivity before and been burned later, so I abide by Crystal's requirement for creating SP's.

BTW, I always create a package, didn't think you could do otherwise.

-k

http://www.informeddatadecisions.com

kai@informeddatadecisions.com

 

[cjmartin]

synapsevampire,

In the Info Designer, I'm assuming you have "Stored Procedures" selected (under File-->Options-->Allow Reporting on as well? I was just playing around the other day and noticed that I have always had that option unchecked.

I learned PL/SQL & how to write Oracle Stored Procs from someone who was self-taught. What we've have always done is create a separate "Create Table" script that may server as a workaround of sorts to not using a Package. I have it on my list of things to do (it's a long list) to learn more about Packages (and the potential benefits and efficiences that can be realized with their proper usage). It just became a much higher priority!

Thanks for your input!

 

[synapsevampire]

Ahhh, a create table script isn't a supported stored procedure used by Crystal, and the report is probably based on the resulting table, meaning that the create table script is ran by an external process.

SP's are great, though CR->Oracle are the most problematic and painful to learn, but they're still not that bad.

CD has an example of creating an SP on their site (sorry, don't htave the URL handy), D/L it and I'm sure that you'll work through it relatively painlessly.

-k

http://www.informeddatadecisions.com

kai@informeddatadecisions.com