report scheduling fails randomly

[crsdev]

Hello Friends

Any suggestion about the following error:

Failed to open the connection. /usr/local/BusinessObjects/bobje/data/procSched/xxx.reportjobserver/~tmpxxxxxxxx.rpt Details: [Database Vendor Code: 12154 ]

the same report works fine sometimes and other times i get this error.
When i run/view(on demand) the report without scheduling it works fine too.

BOXIR2 on solaris.

THanks

 

[Turkbear]

Hi,
That error ( it is Oracle right?) indicates a problem
with the tnsnames.ora file ( or the server that the alias refers to)..Is the target database for the report always up?





To Paraphrase:"The Help you get is proportional to the Help you give.."

 

[crsdev]

THanks for your response Tukbear,
Yes the target database is always up.
The weird thing is you can view the report just fine when you view it on demand or refresh it, so i don't think there is any database connection issue.

It just fails when scheduled.

 

[groggle]

Viewing on demand uses the Crystal Reports Page Server.

Scheduling uses the Crystal Reports Job Server.

Do they both run under the same account?

Are they (the page server and job server) both running on the same solaris box?

 

[crsdev]

yes it's in the same box, but we also have BOXI installed in a different box to cluster it, but we are current not using that and all the servers in that box are disabled.

 

[Turkbear]

Hi,
Can you connect to that database using SqlPlus from the server?

Here are more details about that error:

ORA-12154: TNS:could not resolve service name

Cause: Oracle Net could not locate the net service name specified in the tnsnames.ora configuration file.

Action: Perform these steps:

Verify that a tnsnames.ora file exists.

See Also:
"Localized Configuration File Support" for configuration file location information


Verify that there are not multiple copies of the tnsnames.ora file.
In the tnsnames.ora file, verify that the net service name specified in your connect string is mapped to a connect descriptor.
Verify that there are no duplicate copies of the sqlnet.ora file.
If you are using domain names, verify that your sqlnet.ora file contains a NAMES.DEFAULT_DOMAIN parameter. If this parameter does not exist, you must specify the domain name in your connect string.
If you are not using domain names, and this parameter exists, delete it or disable it by commenting it out.

Given the fact that this only happens with scheduled reports sometimes, I suspect a network issue between the server and the Oracle database server...





To Paraphrase:"The Help you get is proportional to the Help you give.."