I'd like to know if jdbc by itself is compatible with mysql or do I have to intsall something extra? I was told it is not compatible and that I'd have to use a different database.
It does.
You have to use the correct mysql jdbc driver and that's it!
Some useful links:
Little old but still helpful:
Using JDBC with MySQL, Getting Started
Official reference:
Official JDBC Driver
JDBC reference
You have to look at your specific version.
MySQL belogs to Sun Microsystems now after all
Using MySQL from Java
JDBC is a specification for Java/database interaction. As a specification it's compatible with almost every DB. However, you need a JDBC compliant driver written for your database. Googling "jdbc driver {databasevendor}" should get you an the right track.
Related
How can I access ODBC 32-bit drivers with UCanAccess with DNS?
jdbc:ucanaccess:pmg
Here is the 32-bit driver from a custom ODBC driver:
I'm using Java 11 with JavaFX.
Short answer: You cannot.
UCanAccess is a JDBC driver to access databases which were created by the Microsoft Jet Engine, the default database format used by MS Access. It does this by leveraging Jackcess, which is able to read directly the database file format bypassing MS DLLs so it is able to work under Linux.
But if you use Access only as a GUI to access another database like SQL Server or Acomba via ODBC UCanAccess is unable to access those database links.
So you need a JDBC driver for your target database. It seems there is none for Acomba. And the old built-in JDBC-ODBC-Bridge driver is no longer provided since Java 8 and was never intended for production use. There was a commercial JDBC-ODBC-Bridge driver provided by Easysoft. But the Easysoft web site is no longer available. So it seems you are out of luck. Maybe you can implement the data access part with another programming language which supports ODBC.
I am creating a new Spring Boot project (https://start.spring.io/), and I am not understanding the different dependencies provided for interfacing with relational databases.
The point of confusion is "JDBC API" and "PostgresSQL Driver". My app needs to connect to a PostgreSQL database. So, which of the following are true?
JDBC API can be used to connect and operate with any relational (SQL) database (MySQL, PostgreSQL, etc.), and PostgresSQL Driver is not needed for JDBC API to work.
Both JDBC API and PostgresSQL Driver are needed for an application to connect to a PostgreSQL database.
The dependency PostgresSQL Driver includes JDBC API.
I have already googled about this, but there are only manuals of how to use them.
JDBC defines an API to connect and work with relational databases. The PostgreSQL driver is an implementation of this API for the PostgreSQL database.
You cannot use the JDBC API without an underlying driver to implement it. You could, however, use the driver directly, but drivers usually have very little guarantees about the stability of their APIs (other than what's promised by JDBC, of course), so it would probably be a poor idea.
I trying to develop a program, which as a part of it functionality, needs to connect to a selected database(either Oracle, SQL Server, MySQL etc). I am using java for the program. Is it okay for me to use the latest jar file for each database? Will this latest driver support connectivity to all the previous versions of the database. For example if I use sqljdbc4.jar for SQL Server, will it support even older SQL Servers like SQL Server 2000. Or do i need to include all the driver jar files for support and modify code based on version?
The database driver used within your code should match the version of the database you are using. Why would you want to use a newer release of a driver when your not using the database it corresponds with?
With that being said many database drivers are backwards compatible to a certain point. For example, the Oracle 11g Drivers state:
The JDBC drivers are certified to work with the currently supported
versions of Oracle Database. For example, the JDBC Thin drivers in
Oracle Database 11g Release 1 (11.1) are certified to work with the
10.2.x, 10.1.x, 9.2.x, and 9.0.1.x Oracle Database releases. However, they are not certified to work with older, unsupported database
releases, such as 8.0.x and 7.x.
You should investigate your target driver to determine its compatibility with the database your using.
Yes, Most of jDBC drivers are backward compatible. When database are added new features, jDBC driver changes to support new features but will remain compatible for older version.
How can I use MySQL 3.x and MySQL 5.x simultaneously from my Java application if the two versions need different versions of JDBC drivers but the driver class name is the same?
For MySQL 3.x I downloaded MySQL Connector/J 3.0.17 and for MySQL 5.x I have MySQL Connector/J 5.1.12. How can I use them both?
First check whether (as mentioned by #DaveHowes +1) you can use JDBC driver for v5 with DB v3. It probably works. In this case you have no problem.
If it does not work you have to use separate class loaders for 2 connectors to 2 different DBs. So, neither v5 nor v3 JDBC driver will not be in "regular" classpath of your application. Instead you should create some kind of wrapper that will instantiate its own UrlClassLoader: and start driver. The mentioned collector should expose API that allows you to perform JDBC query. I hope this will work. All this if you are using pure JDBC. If you are using some kind of tools (e.g. Hibernate, iBatis etc.) I wish you good luck :) and suggest to ask more specific question that mentions tool you are using.
we have 2 approaches to connecting to our MSSQL databases, the one being the Sun JDBC ODBC bridge and the other being the MSSQL JDBC Driver.
We're doing some reorganization and want a uniform approach to database connectivty.
Which driver should we use?
(I'm leaving the question at a very broad level on purpose, I'd like to hear what peoples opinions are)
Sun's bridge driver shouldn't be used for anything other than prototyping and quick development.
You should always use a type IV JDBC driver if one's available. There are two that I know of for SQL Server: Microsoft's version and jTDS.
Even Sun/Oracle says so. This is from their docs:
If possible, use a Pure Java JDBC driver instead of the Bridge and an
ODBC driver. This completely eliminates the client configuration
required by ODBC. It also eliminates the potential that the Java VM
could be corrupted by an error in the native code brought in by the
Bridge (that is, the Bridge native library, the ODBC driver manager
library, the ODBC driver library, and the database client library).
The JDBC-ODBC Bridge driver is recommended for use in prototyping
efforts and for cases where no other JDBC technology-based driver
exists. If a commercial, all-Java JDBC driver is available, we
recommend that it be used instead of the Bridge.
Use the MSSQL Type 4 JDBC driver provide by Microsoft or the jTDS driver. At the time of writing this, the MSSQL JDBC driver offered by Microsoft is at version 3.0 although version 4 is available as a preview release.
Avoid the Sun JDBC ODBC driver, for it really is a bridge to the ODBC driver installed in the machine. Atleast one question has been asked on StackOverflow on why Type 4 drivers ought to be used as opposed to Type 1 (ODBC bridges) or Type 2 (JNI-based) drivers.
To add to the answers posted in that question, Type 1 (ODBC driver bridges) are to be avoided unless you cannot find a JDBC driver from the vendor. After all, it does not make any business sense to have dependencies on both the ODBC driver offered by the vendor, as well as the Sun JDBC-ODBC driver; any bug encountered in production could be in either. Therefore, if you are making this decision for a line-of-business application, you ought to be using a well-tested third-party JDBC driver (like jTDS or DataDirect) or the vendor provided driver (unless your experience suggests that the driver is poorly written or that the vendor is incapable of resolving issues or providing workarounds in a sufficient timespan).
There is also the OpenLink Multi-tier JDBC Driver for SQL Server...
This driver has its place - where additional security and configurability is required.