I maintain a set of applications that use Pro*C to connect to Oracle 10g databases. These applications are generally involved with moving data from one database to another. In each case a connection is made to the source database and a separate connection is made to the target database. For reasons that are out of my control the target databases are to be upgraded to 11g whilst the source databases are not. I have searched the internet unsuccessfully, well I have posed the problem as many different ways as I can think of in google, in order to determine whether connecting to different versions of the database is acceptable .The only, almost relevant, documentation I can find is this Can anyone point me to any other documentation that would allay my clients fears?
The official client/ server compatibility matrix for Oracle is My Oracle Support 207303.1 "Client/ Server/ Interoperability Support Between Different Oracle Versions". That is probably the documentation that your clients would want to see.
The quick version is that if your application were to use, say, the 10.2 Oracle client, you would be able to connect to databases from 9.2.0.4 to 11.2.0.x. If your application were to use the 9.2 Oracle client, you'd be able to connect to databases from 8.1.7.x to 11.2.0.x. If you used an earlier version of the Oracle client, you would not be able to connect to an 11.1 or an 11.2 database.
Related
What are the supported clients and client versions for Oracle Autonomous Database?
Any connection type supported by Oracle Net Services can be used to connect to Autonomous Database.
Oracle Call Interface (OCI) connections require installing the Oracle client software. For these connections, Oracle Database Client 11.2.0.4 (or higher) or the Oracle Instant Client 12.1.0.2 (or higher) are supported by Autonomous Database.
For JDBC Thin connections, the only requirement is to have JDK8 (or higher) installed.
You can also connect to Autonomous Database using the Oracle supplied tools such as Oracle SQL Developer (version 18.2 or higher recommended)and Oracle SQLcl.
Some of these clients and tools such as JDBC, SQL Developer, and SQlcl support TLS authentication without using any wallet; hence making life much easier as opposed to mTLS authentication, which requires a wallet. I definitely recommend checking out the TLS option without a wallet in ADB since it has several advantages as described in this blog post.
Another great option is Oracle Database Actions if you don't want to worry about supported versions, installing a client, whether to use a wallet or not. Database Actions is a web-based interface that uses Oracle REST Data Services to provide executing your SQL statements and scripts, creating Data Modeler diagrams, developing RESTful web services, managing JSON collections, and using the Data Load, Catalog, Data Insights, Business Models, and Data Transforms tools to load data from local and remote sources, view data in your tables and views, view objects in your data dictionary, and organize, analyze, and transform your data. You can access Database Actions from the ADB details page of your instance in Oracle Cloud Infrastructure console:
I also recommend referring to the documentation for more details on supported clients, client versions, and connection methods.
Disclaimer: I’m a Product Manager at Oracle.
TL;DR:
Is there a way to connect to an Oracle DB via JDBC without the Oracle JDBC driver? Or any other way (e.g. hibernate)?
Full story:
We have an existing Spring Boot app, which connects to an Oracle 11c database instance using OJDBC driver. Spring Boot internally uses JdbcTemplate to execute a few inserts and selects, basically 5 or 6 type of statements. Technically it is working fine.
However we are in an interesting situation, the code we built has to pass through a series of checks (we are working as subcontractors under a larger international company), and part of these checks is a license inspection. BlackDuck (https://www.blackducksoftware.com) is used to report every single library which is linked in the solution (around 280 in our case), and we had to manually add the copyright statement to each (for example: "Copyright © 2005-2019 The Apache Software Foundation. All Rights Reserved."). We added the Oracle Technology Network license to the Oracle Driver, and it was rejected by the legal team of the international company:
"Unless we are actually licensed to use an Oracle database (which you are not), we cannot allow the use and distribution of the Oracle JDBC drivers. Those drivers are licensed under the Oracle Technology network license and it obligates XXX [company name] to designate Oracle as a 3rd party beneficiary, which is not something our legal department allows. You must therefore find a compatible replacement that is licensed under open source."
Now, we are obviously trying to get around this thing (seeing as the end client who is receiving the solution has a licensed Oracle DB installed, and we can see earlier versions of the OJDBC driver in the company's Nexus repository), but I wanted to ask, is there a way to connect to an Oracle DB via JDBC without the Oracle JDBC driver? Or any other way (e.g. hibernate)? To my knowledge, Oracle DB communication protocol is not fully standard, that's why you need the Oracle drivers. Is there an open source alternative that I don't know of?
Oracle DB communication protocol is not only "not fully standard", there is simply no SQL or JDBC standard for any on-the-wire communication protocol for SQL databases, they are all proprietary.
There is no open-source alternative that I'm aware of, and there couldn't be without Oracle's help as the protocol is not publicly specified as far as I know. We solved a similar problem by having our customers with an Oracle license add the driver to their deployment of our app, that way we didn't redistribute it, and they were the ones who used it.
Yes, use someone else's driver. Progress makes one for example.
I'm not speaking on behalf of Oracle in terms of the quality of THIS driver or the legal terms concerning your decision to not use our driver. However, there are alternatives to our driver for Java applications, and this is one of them.
I have only used db links to get access to remote db so far. Now I have to find a way to use JDBC to connect to remote db and get data. Can someone guide me what all things would I need to ask the remote db admin in order to setup a jdbc connection, and once I have the connection, how do I query the database using java stored procedure, just like I am querying it over remote db right now with db link?
You've described a fairly complicated problem, but haven't given any information about your database or operating system. Are you connecting to a SQL Server database? MySQL? Are you running on Linux? Windows?
First, you'll need a driver. That's going to depend on the database, operating system and versions thereof that you're using. For example, here is the Microsoft ODBC Driver for SQL Server (Oops, looks like it's currently unavailable.)
Second, you need to set up Oracle Heterogenous Services. That's fairly complicated and not something I can answer here. You might start with the Database Gateway for ODBC User's Guide.
Oracle does have gateways for various other databases, but they're licensed additionally from the database itself.
My work uses Oracle 10G and is planning on installing Apex. In the meantime, I have downloaded Oracle XE and have taught myself APEX on it; however, I can only access users/tablespaces that I have made in the XE database. What I would like to do is use the XE's Apex to access the users/tablespaces in the production databases of my work.
My colleague says that this should be possible because my workstation is connected to the server, and that there should be a way to configure access from my XE's Apex to the 10g's databases, such as by setting up an appropriate DAD.
I see nothing in the Apex user interface to allow this. I've read every word of the Apex documentation but nothing registered.
XE uses the embedded PL/SQL gateway, as opposed to 10/11G which uses either an Apex Listener or an HTTP Server with the mod_plsql plugin.
Thank you,
Matthew Moisen
I have done this before where we didn't have access to the actual database hosting the data to be worked with save for the standard port 1521 listener access. Apex at the time was new enough to the organization that the DBA's also had a voodoo taboo on using their database server as a webserver gateway as well. You can use your database instance with APEX installed as a "middle tier" or app server with the following steps:
Set up an account on your 10g database that is accessible remotely via dblink.
Set up dblinks to your 10g database table on your workstation with XE installed, use the account and connection information for the 10g database as set up in (1). Note, you may have to update a TNS names file or explicitly indicate your host/networking settings within the dblink itself.
For simple sanity and simplicity in coding your apex projects, set up synonyms for all your dblinked objects (i.e., table1 for table1#dblink) so you're not referencing the dblinks directly in your apex code. Making changes later will be easier if you adhere to this.
That's it. One proviso is that you need to know that LOBs will not work with the out-of-the-box functionality of APEX driven DML operations while using dblinks. This may have changed with the newest version. One workaround you may consider is trying to use a stored procedure which passes your LOB data as a input parameter which will do your DML operation for you.
Otherwise, this approach works nicely. The place where I implemented this model has several production level apps, a test and a development tier all using servers hosting APEX separately from the actual data sources. We used Oracle Standard Edition One (for the support), but Oracle XE should work as well since APEX is the platform in common between either Oracle version.
I support some old web applications, VBScript-based ASP for the UI and VB6 COM modules for the business and data access layers. Last weekend, I installed DB2 Connect Enterprise Edition v8 fixpack 14 on several Windows 2000 servers, and one of the web apps errors out on null data when it calls the built in VBScript function FormatNumber. This numeric data is retrieved by a SQL Server query, but the only way the SQL Server column is populated is with the calculated results returned from a DB2 query earlier in a progression through several pages.
When I installed DB2 Connect EE, one of the components loaded was MDAC 2.7. I followed corporate instructions and had the installation save an ODBC System Data Source, which reported a good connection when I tested it after the install.
For what it's worth, the project references in the production VB6 modules pointed to MDAC 2.5. I have tried recompiling and deploying to COM on my test server new versions of the VB6 modules referencing MDAC 2.7. My development environment is Windows XP Pro, with MDAC 2.8 and DB2 Connect EE v9.5 installed. When I deployed the updated VB6 dlls, the CreateObject fails to instantiate the classes with the error message that "The class does not support automation or the requested interface".
I've rolled the DB2 Connect install back and have reinstall v8 of the DB2 runtime client, which was the previous environment. The problem, however, persists.
I don't really get the picture for how things are connected together - where is the SQL Server and where is the DB2.
There are forums on IBM's site for helping out specifically with DB2 Connect EE, wwhich I think is a pretty pricey product (not sure tho).
One way I have seen people do it is configure a SQL server as the data gateway. You can define DB2 as a linked server, and then perform SQL queries through the SQL server in order to get to DB2. Apps need only to be able to connect to SQL Server, not directly to DB2. They get to DB2 indirectly. Depending on the load on the system this may or may not be feasible for you. You can even do joins across data stored separately in DB2 and SQL with this approach.
It's one more option in the toolbox, along with replication, data federation, and so on. I found that it reduces the variability in connectivity.