REP 51018 - Need database user authentification

[KenCunningham]

Good day. We have a parameterised report which used to run perfectly well when invoked, without prompting for username and password details. Last week it suddenly began requiring these with the REP-51018 message as in the title of this thread.

Does anyone have any idea why this should have changed, when to my certain knowledge there has been no change whatsoever in either the forms and reports server or the database it connects to.

Any help greatly appreciated.

The internet - allowing those who don't know what they're talking about to have their say.

 

[taupirho]

How do you call or run the report ?


In order to understand recursion, you must first understand recursion.

 

[KenCunningham]

Hi taupirho. In all honesty this is something of a blck box to me. The users choose an item from a menu. If this item doesn't require any parameters like a date range or similar, the report runs without a problem. If parameters are required, the validation form for user/password/database is shown, and this seems then to loop between the parameter form and the login form indefinitely, without actually running the report.

The internet - allowing those who don't know what they're talking about to have their say.

 

[taupirho]

I donm't have direct experience with this problem but when I typeds the error code into google, all the issues surrounding this seem to be around

a) cookies either expired or deleted when calling reports from webforms

b) single sign on issues

c) Oracle sessions parameter needing to be upped

Any of these ring a bell with you ?

Sorry I can't be more helpful. Oracle reports are horrible to work with.


In order to understand recursion, you must first understand recursion.

 

[KenCunningham]

No problem - I agree with you! I have seen similar results in searches I have done, along with others involving Java and the like. Basically, I think I'll be spending most of tomorrow testing the possibilities.

I'll post back with the results but in the meantime thanks again.

The internet - allowing those who don't know what they're talking about to have their say.

 

[carp]

Have you tried bouncing your Reports server? We occasionally get this kind of error when submitting a SQL*Loader job from concurrent processes. Bouncing the concurrent managers clears up the issue. Suspect the servers get out of synch and that causes this kind of issue. And when reasoning fails, bouncing often saves the day for no apparent reason.

 

[KenCunningham]

Thanks carp. I've bounced the reports server numerous times to no effect. Still no resolution, but it's weird how it sometimes work and sometimes doesn't - a non-persistent cookie perhaps?

The internet - allowing those who don't know what they're talking about to have their say.

 

[KenCunningham]

Just to put this to bed, it turns out that it was a router configuration that some one had changed, with these unforseen consequences! So, I guess Dima suggestion of DNS or TNS problems gets the prize for closest suggestion, but thanks to all.

The internet - allowing those who don't know what they're talking about to have their say.