Jdbc 4.0 Driver Download
Christian Swindler
To connect with individual databases, JDBC (the Java Database Connectivity API) requires drivers for each database. The JDBC driver gives out the connection to the database and implements the protocol for transferring the query and result between client and database.
The JDBC type 1 driver, also known as the JDBC-ODBC bridge, is a dbase driver implementation that employs the ODBC driver to connect to the database. The driver converts JDBC method calls into ODBC function calls.
The driver is platform-dependent as it makes use of ODBC which in turn depends on native libraries of the underlying operating system the JVM is running upon. Also, use of this driver leads to other installation dependencies; for example, ODBC must be installed on the computer having the driver and the database must support an ODBC driver. The use of this driver is discouraged if the alternative of a pure-Java driver is available. The other implication is that any application using a type 1 driver is non-portable given the binding between the driver and platform. This technology isn't suitable for a high-transaction environment. Type 1 drivers also don't support the complete Java command set and are limited by the functionality of the ODBC driver.
Sun (now Oracle) provided a JDBC-ODBC Bridge driver: sun.jdbc.odbc.JdbcOdbcDriver. This driver is native code and not Java, and is closed source. Sun's/Oracle's JDBC-ODBC Bridge was removed in Java 8 (other vendors' are available).[3][4][5][6]
If a driver has been written so that loading it causes an instance to be created and also calls DriverManager.registerDriver with that instance as the parameter, then it is in the DriverManager's list of drivers and available for creating a connection.
It may sometimes be the case that more than one JDBC driver is capable of connecting to a given URL. For example, when connecting to a given remote database, it might be possible to use a JDBC-ODBC bridge driver, a JDBC-to-generic-network-protocol driver, or a driver supplied by the database vendor. In such cases, the order in which the drivers are tested is significant because the DriverManager will use the first driver it finds that can successfully connect to the given URL.
First the DriverManager tries to use each driver in the order it was registered. (The drivers listed in jdbc.drivers are always registered first.) It will skip any drivers that are untrusted code unless they have been loaded from the same source as the code that is trying to open the connection.
It tests the drivers by calling the method Driver.connect on each one in turn, passing them the URL that the user originally passed to the method DriverManager.getConnection. The first driver that recognizes the URL makes the connection.
The JDBC type 2 driver, also known as the Native-API driver, is a database driver implementation that uses the client-side libraries of the database. The driver converts JDBC method calls into native calls of the database API. For example: Oracle OCI driver is a type 2 driver.
The JDBC type 3 driver, also known as the Pure Java driver for database middleware,[7] is a database driver implementation which makes use of a middle tier between the calling program and the database. The middle-tier (application server) converts JDBC calls directly or indirectly into a vendor-specific database protocol.
The same client-side JDBC driver may be used for multiple databases. It depends on the number of databases the middleware has been configured to support. The type 3 driver is platform-independent as the platform-related differences are taken care of by the middleware. Also, making use of the middleware provides additional advantages of security and firewall access.
Written completely in Java, type 4 drivers are thus platform independent. They install inside the Java virtual machine of the client. This provides better performance than the type 1 and type 2 drivers as it does not have the overhead of conversion of calls into ODBC or database API calls. Unlike the type 3 drivers, it does not need associated software to work.
The Microsoft JDBC Driver for SQL Server is a Type 4 JDBC driver that provides database connectivity through the standard JDBC application program interfaces (APIs) available on the Java platform. The driver downloads are available to all users at no extra charge. They provide access to SQL Server from any Java application, application server, or Java-enabled applet.
Version 12.6 is the latest general availability (GA) version. It supports Java 8, 11, 17, and 21. If you need to use an older Java runtime, see the Java and JDBC specification support matrix to see if there's a supported driver version you can use. We're continually improving Java connectivity support. As such we highly recommend that you work with the latest version of Microsoft JDBC driver.
If you are accessing this page from a non-English language version, and want to see the most up-to-date content, please select Read in English at the top of this page. You can download different languages from the US-English version site by selecting available languages.
Unsupported driver versions aren't available for download here. We're continually improving the Java connectivity support. As such we highly recommend that you work with the latest version of Microsoft JDBC driver.
MySQL Connector/J is the official JDBC driver for MySQL. MySQL Connector/J 8.0 and higher is compatible with all MySQL versions starting with MySQL 5.7. Additionally, MySQL Connector/J 8.0 and higher supports the new X DevAPI for development with MySQL Server 8.0 and beyond.
This question might have asked here number of times . After doing some google search for the above error and doing some update, I can't understand why I'm still getting that error. I've already put my driver-- mysql-connector-java-5.1.5-bin in the classpath:
I too struggled with the same problem and finally got the solution for it.Just copy the MySql-Connector.jar into Tomcat's lib folder, and then remove the jar from the webapp's lib folder, and then, run the project.
The most common cause is that you have some conflict in where your classes are loaded from. For example if you have 2 locations and one has JDBC drivers and the other one not then if your classloader loads from the 1st location and some class from the 1st location wants to use the driver - the driver is not there. So look for the duplicate JARs that are using your driver
By the way, I wouldn't put it in lib, jre/lib or jre/lib/ext, there are other ways to add a jar to the classpath. You can do that by adding it explicitly the CLASSPATH environment variable. Or you can use the -cp option of java. But this is another story.
Most of the possible solution has been covered above. From my experience of this issue, i have placed the mysql-connector-jar in the /WEB-INF/lib folder of the webapp module and it worked fine for me.
I keep the mysql-connector jar with my project rather than in Javahome. As a result, you can be sure it can be found by being sure its in the local classpath. A big upside is that you you can more the project to another machine and not have to worry about (or forget) to set this up again. I personally like including it in version control.
Ok..May be i can also contribute my solution..Right click on project -properties -->Deployment assembly...there you need to add the mysql-connector-java.jar and apply it...which makes your prject configured with web-Libraries that has this sql connector...This worked for me..I hope this works for you guys as well
see to it that the argument of Class. forName method is exactly "com. mysql. jdbc. Driver".If yes then see to it that mysql connector is present in lib folder of the project. if yes then see to it that the same mysql connector . jar file is in the ClassPath variable (system variable)..
The PostgreSQL JDBC Driver allows Java programs to connect to a PostgreSQL database using standard, database independent Java code. pgJDBC is an open source JDBC driver written in Pure Java (Type 4), and communicates in the PostgreSQL native network protocol. Because of this, the driver is platform independent; once compiled, the driver can be used on any system.
Clicking on this will allow you to configure a JDBC driver for connecting. To start you would go to the libraries tab and point at the InterSystems JDBC jar file as shown below. Your path would look something like c:/InterSystemsJDBC/intersystems-jdc-3.2.0.jar (your folder may be different).
The connection to the external data source could not be established. An unknown error occurred. The driver is probably defective. /home/buildslave/source/libo-core/connectivity/source/commontools/dbexception.cxx:400
I've just upgraded our BitBucket Server to 5.2.2 and it won't start with an error message: "The database, as currently configured, is not accessible. Bitbucket is configured to use the mysql driver (com.mysql.jdbc.Driver) but it is not available.".
This is not the first time I was upgrading the BitBucket Server. As it was with the last time I was upgrading it, I've put the latest jdbc driver (mysql-connector-java-5.1.43-bin.jar) in the /opt/atlassian/bitbucket/5.2.2/lib folder. It doesn't matter if I start it with service atlbitbucket start or 5.2.2/bin/start-bitbucket.sh commands, the error is always there.
did it also for me after a G search...
I suggest Atlassian team to update the page Connecting Bitbucket Server to MySQL with a note that informs that from Bitbucket 5.x by default home dir in linux envs has been moved in /var folder.
Had to figure this out for Windows Server 2008 R2 Sp1 - we were getting the same error when trying to launch it in the browser. With a default install of Bitbucket 5.x the path is apparently:
C:\Atlassian\Bitbucket\5.x\app\WEB-INF\lib