[XI 3.1] BEST PRACTICE method of Oracle connection for RPTs on Linux
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 - http://www.forumtopics.com/busobj/viewtopic.php?t=118770&view=previous&sid=9cca754b468fc67888ab2553c0fbe448 [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 - http://www.easysoft.com/products/data_access/odbc_oracle_driver/index.html - 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.
_________________