Friday, February 24, 2012

SRW.RUN_REPORT and the dreaded REP-0178

I was working on a Forms&Reports migration last month (6i to 11gR2) and had little trouble upgrading the entire application, except for one small part: some reports were used as a starting report, calling other reports (based on various criteria), using SRW.RUN_REPORT to do so.

SRW.RUN_REPORT was calling the other reports using both the "userid" en "server" parameters, which were deprecated in 10g. Using the "userid" will net you an Oracle error: REP-01434.
If you set the "REPORTS_SRWRUN_TO_SERVER" environment variable to YES, this error can be avoided, but I chose to eliminate these keywords altogether (as there weren't that many reports that used them). So after this, I expected the reports to run smoothly...

When invoking the starting report via the URL, the report itself ran OK, but the SRW.RUN_REPORT did not. Eventually, in the rwEng-0_diagnostic.log file In found only “REP-1428 An error occurred while running procedure SRW.RUN_REPORT in program unit beforereport”. Not much help there.

Because the SRW.RUN_REPORT effectively calls rwclient.exe (it’s a Windows 2008 implementation), I tried using rwclient from the command box. At first, this didn’t work either (REP-0178 Cannot connect to Reports Server), until I saw that one of the rwclient.bat scripts invoked reports.bat (setting the environment) and the other did not. When setting only two environment variables (ORACLE_HOME and ORACLE_INSTANCE), rwclient.exe also worked.

Encouraged by this, I set these two environment variables as system variables, so they will always be available for any program. Just to be sure, I rebooted the entire server as this was only an acceptation server at the moment. After reboot, the reports using SRW.RUN_REPORT also worked. Mission accomplished ;-).


Some details of the environment:
• OS = Windows 2008 R2
• AS = WebLogic 10.3.5
• FMW = 11.1.2 Forms&Reports Services
• Database (different server) = 11.2.0.3

4 comments:

  1. Hi there... I'm having the REP-178 as well. We are running on Solaris 10. The problem is random and started happening right after we upgraded to OAS Forms and Reports 10.1.2.3. It's like the report server takes hours to startup... then it runs great for a few days then stops, then recovers on it's own. Can't replicate on out test box... frustrating... Any ideas? thx.

    ReplyDelete
  2. Hi "Anonymous",

    I have no particular experience with Reports 10.1.2.3 on Solaris, but in my experience, you should be looking at the configuration of your reports engines. What I usually do, is set the minimum eninges to a value greater than 0 (1 or 2, but mostly depending on the rest of your configuration), ensuring that there will always be at least one engine available when needed. Further, set the lifetime of the engine not too high, so it will respawn after a fair number of executed jobs. So far, this has worked for me.

    ReplyDelete
  3. Hi, thank you for the response. I agree, it does seem related to these settings. We've tried a number of different configuration settings, maxEngine, minEngine, engLife etc... It has not helped unfortunately. I'll keep trying. Also, our qual/test box has all the recommended settings from the vendor and it works perfectly. Not so for our prod server. The only thing different btw qual and prod servers is the OS patching levels. Qual is solaris 10 - level 9 and prod is only at level 7. Now, the Oracle installation package is suppose to validate OS patch requirements before it continues, but perhaps something went wrong. We've enven re-installed OAS on our prod box in an entirely new directory and the connection problem persists!

    ReplyDelete
  4. Hi,

    I'm sorry to say that there seems to be only the obvious answer: upgrade your Prod to level 9, just like the Qual... I know it's the answer you'd most likely get from Oracle Support too, but for now, it's all I can think of.

    As for the OS patch requirement checking: it is very well possible that the requirements check passes, but that a bug is now causing trouble. The only way to find out seems to upgrade (preferably on a separate machine first).

    ReplyDelete