Re: REP-736 message - where do I look next?

From: anacedent <anacedent_at_hotmail.com>
Date: Tue, 06 Jul 2004 16:53:43 -0700
Message-ID: <5YGGc.10806$nc.10214_at_fed1read03>

Sally Pearce wrote:

> "Smiley" <Anoniemke888removethis_at_hotmail.com> wrote in message
> news:40e59dd1$0$757$3a628fcd_at_textreader.nntp.hccnet.nl...
>

>>Sally Pearce wrote:
>>
>>>our current set up is:
>>>Oracle 7.3.4  :-(
>>>Reports 2.5   :-(
>>>Unix V rel 4.0
>>>
>>>I'm all too aware that we're in the stone age, as far as versions are
>>>concerned, but there's not a lot I can do about it at the moment, so I'm
>>>having to live with it.
>>>
>>>The problem is that I'm required to modify a report that currently runs
>>>perfectly on production (same versions of everything as the test server)
>>>but, when I copy it over to the test server, so that I can see how long

>
> it
>

>>>takes to run before I fiddle with it I get the message:
>>>REP-0736: There exist uncompiled program unit(s)
>>>Ok, I thought, maybe our test database isn't the same as the production

>
> base
>

>>>so I cloned test from production
>>>same message REP-0736: There exist uncompiled program unit(s)
>>>OK, maybe I'm running the wrong version of the report or copied it over

>
> in
>

>>>ascii mode, so I ftp over the report from the production server again
>>>(making sure I use the bin option)
>>>same message REP-0736: There exist uncompiled program unit(s)
>>>Hmm, maybe I'm picking up an old version of the report from somewhere

>
> else
>

>>>on the server.
>>>Ran 'find' on the server - no other copies of the report anywhere.
>>>I then copied the report over to a different test server, running the

>
> same
>

>>>*nix flavour, same Oracle and reports version, and the report runs with

>
> no
>

>>>errors. . . . .
>>>Tried technet - no useful hits on REP-0736 (probably because the reports
>>>version is too old?) except for where it specifically related to a

>
> report in
>

>>>an Oracle application and suggested that copying without using the bin
>>>option might be the source of the problem.
>>>Tried tahiti.oracle.com with the same search - no hits found.
>>>
>>>Does anyone have any idea what might be up or suggestions as to where to
>>>look next. I must be doing something daft but am stumped as to what it

>
> could
>

>>>be.
>>>
>>>TIA
>>>
>>>Sally
>>>
>>>
>>
>>Just open the Report (.rdf) in Report Builder (or was it called Reports
>>Designer in those days...) and compile it (Ctrl+Shift+K). Then try to
>>run it in Report Builder.
>>Hth,
>>
>>:)

>
>
> The report runs happily in Reports Designer, and on production and on the
> other test server. . . To be honest, I wouldn't have bothered about it not
> running on this particular test server were it not that this is the
> development server for a different instance of the database (slightly
> different application parameters) and I wanted to test the report against
> all our different instances before putting it into production (been bitten
> too often by that not being done)
> It'll probably work just fine in production but I don't want to have to
> stick my hand up and say 'oops, no, I didn't test against this particular
> database' :-(
>
> Thanks for the suggestions everyone.
>
>
One NOTE I found in MetaLink indicated that the runtime engine is not the same version as the engine which made the form. I forget/forgot which is/was supposedly the older of the two. Received on Wed Jul 07 2004 - 01:53:43 CEST