it throws exception trying to review History for a scheduled report

[Former Member]

Hi, guys.

May be somebody will help me out.

There is a scheduled report and it works fine on development server. I can schedule and review the history. it works.

Then I've exported the report using Wizard to biar file and imported into another server.

When I'm trying to view History of scheduled reports it shows the following message 'An error has occurred: java.lang.NullPointerException'. Meanwhile, it looks like the report was run because time-stamp is updated and the number of report instances > 0.

Any idea what is going on?

[Former Member]

Data needs to be purged before exporting reports to biar file.

[Former Member]

Michael,

Can you launch the report not using scheduler/history yourself in either InfoView or WebI? Perhaps a syntax error has crept into the report from the time it was copy and imported...

Thanks,

John

[Former Member]

thanks for communicating back to me.

Yes, I can view report using Webi, but when I'm trying to schedule or review history it throws the error. it only happens on target server, not the development one.

I've google the error and found out the problem exists from 2002 and described on BOB forum and has something to do with security level. not clear....

[Former Member]

Michael,

The security level that is mentioned translates to: security settings are an individual per server concept. If userA is built in Dev and the admin grants him a bunch of stuff and life is good, then ok. When userA report is transported to Prod server and userA now logs in to Prod but admin has not granted userA the same exact bunch of stuff and userA runs his report, now life is not good and errors are thrown. When the report is transported none of the security surrounding the report get transported. When userA is transported from Dev to Prod, if he is a member of a group, and group security was applied on Dev, then the admin must get on Prod and verify that the same security was/is conveyed. In some cases the admin must apply security twice, once in Dev and again in Prod.

Good Luck!

John

[Former Member]

John, thanks, but I'm using administrator account on deploy server and it is supposed to have all priviliges...

Meanwhile, somebody on BOB suggested to clear all report instances using Instance Manager. I've deleted all instances and after was able to view empty history w/o the error thrown. But after saving scheduling report and clicking button 'Schedule' , it throws the same error again and History got contaminated in the sense of the error.

So, now I'm back to source of the problem: the error is thrown during scheduling but it still saves the scheduling to instances but History can not be reviewed because of the same issue.

do u think it is security issue for administrator?

thanks

[Former Member]

Michael,

You've got quite a case going on and it's stumping me (don't take much to stump me though, smile).

How about try this. Open the report in WebI and save it with a new name, then schedule that new name and see what happens -- this is a shot in the dark. If it works, then it tells us something about the transfer process and how something (ghost-like) is coming across, however, saving a new report breaks the pattern. At this point I'm thinking that getting tech support on the line may be the best solution....

Thanks,

John

[Former Member]

John,

thanks for your worry, but there is good news: I got it fixed.

Let me describe what is happening....

The reports on dev server had some data associated with and when we did export to prod server data were imported into, too.

Now, without refreshing report under prod server, we were trying to schedule and it throwed the exception. Then, I've deleted report instances and refreshed reports using data on prod server, save it and after that I was able to schedule w/o exception thrown and view history.

The lesson learned is purge data on dev server (or some distribution server) before exporting (keeping only meta-data like universes, reports, scheduling and etc) to biar file, then import to prod server. I hope it will work, need to do more testing for the last case.

again, thanks for being with me during that hectic time

Michael

[Former Member]

Michael,

That is quite a lesson learned and thanks for passing back what is happening. I'll have to take note of this in case I ever wind up moving BIAR files around and old instances hanging around.

Thanks,

John