I have spent a few hours trying to track this one down. A lot of people have reported this error, but ultimately a solution was found. But, none of those solutions worked for me.
I'm developing a Java application using Eclipse. Here is a code snippet:
import java.sql.*
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
Eclipse spots an error immediately: Unhandled exception type: ClassNotFoundException.
Project properties indicate the build path includes JRE System Library (jre7).
In Eclipse, I can see that JRE7 includes sun.jdbc.odbc.JdbcOdbcDriver.class
Class.forName() declares that it throws ClassNotFoundException. And this is a checked exception. So you must catch it, or declare that your method throws it as well.
Learn about exception handling by reading the Java tutorial. This is basic stuff that every Java developer must know.
Once you master exceptions, please learn about JDBC. The JDBC-ODBC driver is something that should not be used anymore, for years. Every database now has a native JDBC driver.
"Every database now has a native JDBC driver."
I wish this was true - however there are niche database systems that do not. At my work specifically we are stuck with a database system that is part of a larger piece of software that we need to run the business and cannot easily replace. There is no JDBC driver for it and the developers of the database system have clearly stated that creating one is not a goal of theirs.
You may have good reason to not like the JDBC-ODBC driver, but there are cases where it is the only option.
Related
This link explains the new things about WildFly. Under the Migrating The Database Connection -> JDBC Driver the article explains about two ways of using jdbc drivers for the applications. I tried with installing it as a module and it works fine. The problem is which way is better and when it is better, whether deploy it as any other application package or install it as a module?
(I noted that install it as a module is necessary for clustered environment. I am looking for, are there any other reasons?)
I think the correct link to the article you are referencing is this one : http://wildfly.org/news/2014/02/06/GlassFish-to-WildFly-migration/
(The other one does not seem to point to the article you are mentioning)
Below is the interesting part from "Migrating The Database Connection" section you are referencing:
On WildFly, you have two ways of installing the JDBC driver: whether
you deploy it as any other application package or you install it as a
module. You can always choose to deploy the driver, but it’s specially
recommend when you have a cluster environment, since the deployments
are automatically propagated in the server groups.
You may have issues with the deployment if the driver is not
JDBC4-compliant. In this case, installing the driver as a module
solves those issues. The advantage of the JDBC driver as a module is
the possibility of creating a custom WildFly bundle for your
organization. This way, you can repeat exactly the same installation
throughout several machines, preserving the same configuration. This
is perfect for the development environment.
So in this section, the author describes the following advantage:
You may have issues with the deployment if the driver is not JDBC4-compliant. In this case, installing the driver as a module solves those issues.
The following Wildfly documentation describes this also:
Any JDBC 4-compliant driver will automatically be recognized and installed into the system by name and version. A JDBC JAR is identified using the Java service provider mechanism. Such JARs will contain a text a file named META-INF/services/java.sql.Driver, which contains the name of the class(es) of the Drivers which exist in that JAR. If your JDBC driver JAR is not JDBC 4-compliant, it can be made deployable in one of a few ways. (...)
Thus, deploying your driver as a module is easier than deploying it as any other application package in case it is not JDBC-4 compliant. (Because you would have to modify and rebuild your JDBC-4 not compliant jar to deploy it as any other application package)
In my previous spring projects, I always use hibernate+postgresql to store the data. I rencently start to use spring-boot, and I am looking for a database system which allow me embed it in my project, without be required the installation of a external DBMS.
I try use SQLite, but in my searches I found some afirmations Hibernate isn't compatible with SQLite.
Anyone knows if this is possible and could point me a solution?
We've successfuly used HSQLDB with Hibernate for ages.
This is actually super cool for sales, you can demonstrate a working application on (potential) customers machine with the embedded HSQLDB database. And still be able to switch to "the real thing" later on.
See also this:
Does Hibernate Fully Support SQLite
and this:
https://code.google.com/p/hibernate-sqlite/
Admitting I am not a Avaje Ebean expert or a JDBC expert either. I use play framework and Ebean in the "normal" use cases (H2 and mySQL basically) and they perform fine for me.
I found recently about the cassandra-jdbc driver project and was wondering if I could naively make them work together. So I tried and, once I turned off evolutions, I got a SQLFeatureNotSupportedException because cassandra-sql force autocommit always on.
I wanted to know if there is a way to make them work together since the driver claim to be Jdbc compliant and Ebean should be able to work with that. Is there something in the way Ebean use the drivers that make this impossible?
Although the cassandra-jdbc driver is jdbc complient, at the moment its not possible to use cassandra as the backend for your playframwork #Models.
There are a few projects trying to implement support for NoSql, although not explicitly cassandra, in the play framework, have a look at siena.
Also this SO question might be a useful reference.
I am trying to understand the difference between XA vs Non XA JDBC datasource. Also how do I know which type and version of JDBC dtriver is used. I am currently on 10.3 weblogic and trying some tet to kill long running queries using setQueryTimeout, which isnt seem to be reliable with OracleXADataSource as it is only working the first time and not always.
Sorry for this basic question but I am new to Weblogic Datasource configuration
Thanks
XA jdbc drivers are used to implement two-phase commit, meaning the two remote resources are part of the same transaction. Java specifies an implementation of this via JTA. A good reading is e.g. http://www.javaworld.com/javaworld/jw-07-2000/jw-0714-transaction.html; if you google for 'xa jdbc driver' you'll find plenty more info.
You should not use the XA driver if not necessary. I remember reading that there are some problems with them.
To identify JDBC driver your WLS is using, go to the <domain_dir>/config/jdbc and open the data souce file, check the driver-name value in the file.
To identify the Driver version, check from which .jar is the driver being loaded (run the WLS with -verbose:class)- the name of the jar will contain the version number. Also, you can use java -jar my-jdbc-file.jar which will print the driver version. The OJDBC drivers are usually stored in a file named ojdbc6.jar or ojdbc7.jar, etc.
I'm writting custom JDBC driver for my datasource. I'd like to use it with Business Objects product from SAP. My driver works fine in Squirell SQL, but when installed in Business Objects (specifically Universe Designer) I'm unable to fetch table contents. I've enabled TRACE for whole Business Objects instance and the problem's log looks like this:
dictionary_thread::Columns : CS:Unexpected behavior
com.businessobjects.connectionserver.RDBMSDictionary}.Columns: [com.sap.connectivity.cs.core.CSError: Unexpected behavior
As for debugging my JDBC driver, I've been using log4jdbc as well as custom logging of method calls and return values (via aspects) and I don't see any errors, exceptions coming from my driver.
Perhaps someone knows a solution for this, or knows how to debug this further?
It seems obvious that my driver is not fully JDBC specs comformant, so any Test Suite which could analyze errors in my driver would also be of use.
The JDBC API Test Suite 1.3.1 is quite outdated but it may help you diagnose your issue, at least for JDBC 2.0 API: Download is no longer available, remains an old Documentation
According to JSR221 for JDBC4 you may ask for JavaSE TCK (JCK) sources at no charge but you have to follow this process. You will have to accept OpenJDK TCK license.