We will upgrade out IBM DB2 9.7 LUW to 10.5 LUW. Do we have to upgrade our JDBC driver too, or can we use existing one from 9.7?
Normally you should, in order to have everything at the same level. Each release has an upgrade in the JDBC drivers. You can check this page to see the different JDBC versions: http://www-01.ibm.com/support/docview.wss?uid=swg21363866
In addition, you can check the list of APARs to check if you must change it because of an error. To see the list of enhancements in each version please visit the following link and look for the JDBC section of each fixpack: http://www-01.ibm.com/support/docview.wss?uid=swg21633303
IMO, it depends. I'd check to see if the newer driver includes support for additional features that I want to make available to my application. If you don't need any of the new functionality the motivation to change the driver is reduced. If you have already been using the older driver with your app with no issues then you probably are not affected by any defects that are fixed in the newer driver. Keeping the same driver in place might reduce the QA you have to do as a result of upgrading the database. It would also mean you would not have to push a new driver out to all of your clients. You already know the driver you are currently using plays nicely with your app so by keeping it you can minimize the variables in the upgrade.
The protocols between the two databases are the same with the exception of new functionality added to 10.5. I can't really speak for what IBM supports in this regard but we (DataDirect) support multiple version of the database from one version of the driver. I suspect the same is true with the IBM driver. If you are curious to see how we handle it, we have a support matrix, that shows what versions of the database our current JDBC driver supports.
Related
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.
We have an external server service running Oracle and we can not access his configuration. We have the code for the application and we are interested in the current implementation of connection.close().
So the question is, running a Oracle 12c database, is it possible to connect to the database using older database driver version such as Oracle 11g? We want to exclude a simple configuration problem by drivers not matching the database product version.
Is there any document (other than JavaDoc) that specificates the implementation behaviour of Connection.close() since the Java spec says its implementation depending and there is no general rule.
If you have Metalink access, you can check MOS note 207303.1 on Client-server interoperability.
In summary, Clients 11.2.0 and above are fully supported; 11.1.0 is supported, but bugfixes are possible only for customers with Extended support.
I wanted to use Oracle 11g as my db for java code. I tried to get the drivers from the oracle website.
I saw so many files with some jargon thrown in here and there. I need to know what those words mean and how they affect me as a user. How do I decide which one to use ? I picked ojdbc6.jar because I use jdk 6. Please help me to understand what the descriptions of the file mean and who should be concerned about them and why ?
ojdbc6.jar - Classes for use with JDK 1.6. It contains
the JDBC driver classes except classes for NLS support in
Oracle Object and Collection types.
ojdbc6_g.jar - Same as ojdbc6.jar except compiled
with "javac -g" and contains tracing code.
ojdbc6dms.jar - Same as ojdbc6.jar, except
that it contains instrumentation to support DMS
and limited java.util.logging calls.
orai18n.jar - NLS classes for use with JDK 1.5, and
1.6. It contains classes for NLS support in Oracle
Object and Collection types. This jar file replaces
the old nls_charset jar/zip files.
xdb6.jar - To use the standard JDBC4.0 java.sql.SQLXML
interface with JDBC 11.2.0.3, you need to use xdb6.jar
(instead of xdb.jar) from the 11.2.0.3 distribution.
EDIT -
Btw, what is the SimpleFan.jar for ? I saw that too.
Thanks.
Sounds like you picked the right one.
The "_g" one would be needed if you needed to step through the Oracle JDBC code, which is unlikely.
The "dms" version supports fancier monitoring of the db. Again, not something you'd typically use.
"orai18n.jar" would be needed if you wanted to go whole hog with internationalization support.
xdb6.jar would be needed if you wanted to make use of SQLXML to store and process XML documents within the database.
The good news is ... if at any point you realize you do need any of these extra capabilities you can just swap out the jar and be on your way!
I have CF9 Developer Edition installed on Mac OS X 10.6. I have set up datasources successfully to the localhosts MySQL. However, I have taken on a website which uses a Microsoft Access database: fine on the actual server, but to work on the site offline I need to set up the datasource to talk to the Access database.
For some reason, there is no Microsoft Access option in the Add Driver list when setting up a new datasource in the CF admin.
Any ideas on what I need to do would be most helpful.
There is no mac driver for Access available.
You can upconvert your database to the free edition of SQL Server. It's probably a good idea to convince your customer to migrate from Access to SQL Server anyways.
Whilst I'd very much second the comments above regarding getting off of Access if you can, there does appear to be a couple of type-4 (pure java) JDBC access drivers (although I've not used them)
http://www.hxtt.com/access.html
This article links to two drivers. Neither are free but both have evaluation periods on them which may get you through what you need to do.
http://www.razorsql.com/articles/ms_access_mac_os_x.html
You should be able to use these as custom JDBC datasources in ColdFusion.
let us know if you have any success.
There's proprietary read-only driver available.
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.