Showing results for 
Search instead for 
Did you mean: 

[XI 3.1] BEST PRACTICE method of Oracle connection for RPTs on Linux

Active Participant
0 Kudos

Business Objects XI (3.1) - SP3.

Running on Red Hat Enterprise Linux OS.

7,000+ Crystal Reports 2008 *.rpt objects ONLY (No Universe / No WebI).

All reports connecting to Oracle 10g databases.


In the past, all of this infrastructure was running on Windows Server OS and providing the database access via a Named ODBC connection (eg. "APP_DATA".)

This made it easy to manage as all the Report Developers had a standard System DSN called "APP_DATA" which was the same as the System DSN name on all of our DEV, TEST/UAT, and PROD servers for Business Objects.

When we wanted to move/promote a *.rpt file from DEV to PROD we did not have to change any "Database Connection" info as it was all taken care of by pointing the System DSN called "APP_DATA" a a different physical Oracle server at the ODBC level.

Now, that hardware is moving from Windows OS to Red Hat Linux and we are trying to determine the Best Practices (and Pros/Cons) of using one of the three methods below to access the Oracle database for our *.rpts....

1.) Oracle Native connection

2.) ODBC connection

3.) JDBC connection

Here's what we have determined so far -

1a.) Oracle Native connection should be the most efficient method of passing SQL-query to the DB with the fewest issues and best speed [PRO]

1b.) Oracle Native connection may not be supported on Linux - [CON]

1c.) Using Oracle Native would require special-handling on the *.rpts at either the source-file or the CMC level to change them from DEV -> TEST -> PROD connection. This would result in a lot more Developer / Admin overhead than they are currently used to. [CON]


2a.) A 3rd-Party Linux ODBC option may be available from EasySoft - - which would allow us to use a similar Developer / Admin overhead to what we are used to. [PRO]

2b.) Adding a 3rd-Party Vendor into the mix may lead to support issues is we have problems with results or speeds of our queries. [CON]


3a.) JDBC appears to be the "defacto standard" when running Oracle SQL queries from Linux. [PRO]

3b.) There may be issues with results or speeds of our queries when using JDBC. [CON]

3c.) Using JDBC requires the explicit-IP of the Oracle server to be defined for each connection. This would require special-handling on the *.rpts at either the source-file (and NOT the CMC level) to change them from DEV -> TEST -> PROD connection. This would result in a lot more Developer / Admin overhead than they are currently used to. [CON]


We would appreciate some advice from anyone who has been down this road before.

What were your Best Practices?

What can you add to the Pros and Cons listed above?

How do we find the "sweet spot" between quality/performance/speed of reports and easy-overhead for the Admins and Developers?

As always, thanks in advance for your comments.


Accepted Solutions (1)

Accepted Solutions (1)

0 Kudos

Hi Mark,

1. Oracle does have a Linux client for 10.1 and above: I have not tried these but they are Oracles.

2. There is one other option. How about using our[ DataDirect ODBC 5.3 driver for Linux|]? These are the Drivers we have always installed and/or made available for down with our products. We put them as a separate install so if there are issues or updates from DD we can simply make them available on our download sites.It is true it is a third party driver but it is an OEM build for us and fully supported.

3. But I do agree that native is always the way to go, more management for upgrading but there are no added connection layers to process the data.

I also agree with JDBC, not platform specific but not the most efficient drivers.

As for which one.... Personal opinion only though.

Ease is to use the DD ODBC drivers.

More efficient would be the Native client.

JDBC, looking forward it may be the way to go as long as performance is not that much of an issue.

In ALL cases though it may mean you will have to verify all of your reports, or at least update the connection info for each report. There can be slight differences when changing driver, nature of the beasts....

You may want to post your question to the BOE Admin forum also to see if their is anyone in that forum who has more info or more details or recommendations....

Or if you have a Support Contract create a case in SMP and discuss with a Rep. You may want to contact our Profession Service also...

Thank you


Answers (2)

Answers (2)

Former Member
0 Kudos


I just saw this article and I would like to add some infos.

First you can quite easely reproduce the same way of working with the odbc entries by playing with the oracle name resolution on the server. By changing some files (sqlnet, tnsnames.ora,..) you can define a different oracle server for a specific name that will be the same accross all environments.

Database name will be resolved differently regarding to the environment and therefore will access a different database.

Second option is the possibility to change the connection in .rpt files by an automated way like the schedule manager. This tool is a additional web application to deploy that can change the connection settings of rpt reports on thousands of reports in a few clicks. you can find it here :

The last option is to do it with a small sdk script, for this purpose, a few lines of codes can change all the reports in a row.

After some implementations on linux to oracle database I would prefer also the native connection. ODBC and JDBC are deprecated ways to connect to database. You can use DATADIRECT connectors that are quite good but for volumes you will see the difference.

Active Participant
0 Kudos

Don, thanks for your quick and detailed response!

Good to know that most of my assumptions were going in the right direction.

Since the RPT-Developers will be staying on Windows PCs, but our BOE servers will be LINUX - we are trying to find the easiest way to ensure a "similar and stable" method of Oracle connection that will need the least re-testing when we promote them to the Servers.