I've used JDBC in several applications now to query Derby, PostgreSQL and now MySQL databases. I guess I'm choking on some basic terminology in my attempt to understand what is actually going on underneath the hood. Several terms I've seen batted around:
ODBC
JDBC Driver
Bridge
JDBC-ODBC Bridge
For each of those I did my best to do some digging and gain an understanding of what they are, what they do, and how they relate to one another. I believe I'm about 70% of the way there, I just can't seem to find anything (articesl, blogs, docs, etc.) that tie everything together nicely and confirm my suspicions.
It seems that ODBC is a C library (perhaps a DLL?) that programs can use to communicate with RDBM systems (such as PostgreSQL and MySQL). All queries to these systems flow in and out of this library on a given system.
The JDBC-ODBC bridge is a Java component that contains native code that allows JDBC to communicate with that ODBC library on a given system.
JDBC is a pure Java API for querying RDBM systems.
A JDBC driver (such as a PostgreSQL-JDBC Driver) is where I'm really having trouble. If all RDBM systems follow RDBMS standards, and can communicate with the ODBC library, then why does JDBC need different "drivers" for each of them?
What are these drivers? What do they do? Why are they necessary? Also clarification on any other assertions I've made here would be enormously appreciated. Thanks in advance!
You are almost there. Good question.
What are these drivers: A pure JDBC driver is a driver written in Java, that does not need an ODBC driver to work. You should only use ODBC drivers (through JDBC-ODBC bridge) when you don't have a direct JDBC driver for your database (which is extremely rare, since most {if not all} databases support JDBC nowadays).
A pure JDBC has the advantage of not needing ODBC. ODBC is usually hard to configure, and requires a database native client library to be installed on the system (such as Oracle OCI, or Sybase CT Library).
It used to be the case that ODBC or native drivers were chosen for performance reasons, but I think today pure Java/JDBC perform almost as good as their native/ODBC counterparts.
What do they do: the same as ODBC. A standardized Java API to access relational databases.
Why are they necessary: They are necessary because it simpler to work with them, you just need the JDBC library JAR and your URL connection. Opposed to: native client library + ODBC driver + JDBC-ODBC configuration. It's also the case that every single database has its own network protocol to perform queries against it, and to get results back. So you need one driver for each database vendor. Each one of them implements the specific protocol it needs to connect to its relational database manager. If you were on a world where all database shared the same SQL language and the same communication protocol, you would only need one driver. But that won't happen any time soon.
ODBC and JDBC are equivalent. They both use drivers to transform ODBC (or JDBC) calls into the native database commands. ODBC is older and written in C/C++, while JDBC is written in Java. When JDBC came out, there were no JDBC drivers for most DBs, so they created the JDBC-ODBC driver to allow people to utilize the already available ODBC drivers. This is rarely used now, since almost every DB has a pure Java JDBC driver
Just because DBs use "standard" SQL (and that's in quotes for a reason), does not mean that the DB use the same lower level protocol for communication. SQL is simply a syntax, but not a protocol.
The protocols for Postgres and, say, Oracle are wildly different and offer different features, even though they both use similar SQL features.
SQL itself, while standard, has wide deviations in implementations. MySQL for example is notorious for being less SQL compliant than other DBs. While much SQL used today is portable across DBs, there is much that is not.
JDBC and ODBC are kindred spirits. They provide a shared interface that your application can use to talk to an RDBS. They also provided a common model for vendors to implement. These are the drivers.
Vendors implement a driver to allow a JDBC/ODBC compliant program talk to their database. The drivers task is convert ODBC/JDBC calls in to the appropriate SQL or and other control calls for the database.
The JDBC/ODBC Bridge is a JDBC driver that talks to an existing ODBC driver. It's an abomination. Don't use it. Every database of note today has JDBC drivers. And stick with "type 4" JDBC drivers if at all possible, since these are native Java rather than "type 2" drivers that use JNI to a binary. Buggy type 4 drivers give exceptions, buggy type 2 drivers give JVM crashes which nuke your appserver. No thanks.
You're right; you're very close to having the full picture!
JDBC and ODBC are conceptually very similar. They're both frameworks for interacting with databases. JDBC is Java-specific, while ODBC is Windows-specific. That said, both JDBC and ODBC are actually toothless APIs. In Java terminology, JDBC is actually a set of unimplemented interfaces. While they specify a behavioral contract, they don't inherently know how to talk to any specific database. That's where drivers come in.
Let's talk specifically about JDBC here. JDBC drivers are concrete implementations of the JDBC interfaces that actually know how to talk to an underlying database engine. JDBC guarantees that a ResultSet from the MySQL JDBC driver will behave the same way as a ResultSet from the Postgres JDBC driver.
As others have pointed out, a JDBC/ODBC bridge is just a bit of glue to make code written for JDBC to work with ODBC infrastructure. Generally, that only makes sense if you know with certainty you're writing Java for Windows exclusively; ODBC is Windows-specific, but JDBC is (in theory) cross-platform.
Jdbc is the java way to connect to a database using dricers written in java (since JDBC4).
ODBC is the MS Windows way to connect to a database, these drivers are usually written in C
A JDBC-ODBC Bridge is something rather old, in early days of java there were not all drivers in a JDBC version available, so the build a generic bridge beteween JDBC and already existing ODBC drivers.
Related
I was wondering if I could get some advise/suggestions if anyone has experience with the following situation.
So I want to develop a java web app that "talks" with a database that is already built out in .NET. I have experience coding java web apps in eclipse that talked to MySQL DBs so I don't think the database language is that concerning.
What methods would you go about to implement this? Are there certain programs that are more useful than others? What frameworks should I use? Also, examples that I found on the web seem so dated style wise, are there things I can do to web apps coded in eclipse to give it some pop?
Thank you in advance
Microsoft has a JDBC driver for MSSQL.
Refer to: http://msdn.microsoft.com/en-us/sqlserver/aa937724.aspx
Call me JDBC on any database.
In these days, from the point of database vendor, they will give us a nice library (driver) to communicate their product from any (widely using) programming language.
Java is a big dealing programming language in world wide, so don't worry about database connection as this can be done by a jar featuring JDBC.
So your challenge is JDBC driver to suite and map to required database brand and its version.
You just need to worry to be right plug between the database's version and the JDBC driver library (jar file) version. Don't care on any database of MySQL, Oracle, MSSql or so on.
Java app -> JDBC Driver -> Database
Famous database's JDBC drivers;
MSSql JDBC Driver (What you need one?)
MySql JDBC Driver
Oracle JDBC Driver
Are there any other means of connecting java applications to DB other than JDBC? Like when we use Hibernate in our java apps, i believe Hibernate internally used JDBC mechanism to eventually connect to DB.
So my question is that is JDBC the way in which we connect to DB?
Thanks
In general, JDBC is practically always used to connect to SQL databases, either directy or under the hood by an ORM. NoSQL-Databases use other APIs.
In my opinion, JDBC would be the first choice so really would not be seeking alternatives. That said, one could use the JDBC-ODBC bridge. Your app is still written to JDBC but the connection to the DB is with an ODBC driver. I would much prefer the fully Java approach of a JDBC driver. Depending on what database you want to access, they may have Java libraries that expose their native API and you could write to that. Bur, your code would be completely non portable to other database if you ever wanted to expand. A well written JDBC app should be able to access different databases simply by plugging in another JDBC driver and adding the appropriate connection information. Also, if you needed an assistance later on with JDBC being fairly widely used it will be easier to get than assistance than with a native solution.
I am left wondering why you're searching for alternatives to JDBC though.
JDBC is a standard all ORM tools need to follow while connecting to DB using Java
The JDBC-ODBC bridge is no longer supported with Java 8. Is there a way to access legacy MDB files without the bridge in Java 8? By legacy, I mean Access 2.0. Such old version is not supported by UCanAccess, which was suggested here.
Not sure what you're using the database for - but limited use might open up more options.
Try mounting your database with Microsoft Access Database Engine 2010 Redistributable. Probably needs exclusive access to the database.
Can you export the database to a flat file or import it into another JDBC-enabled database format? Either Access or another database format? Would require copying the database - probably only work for reporting or read-only access.
Set up a sync process to mirror the database into something modern. Some in-memory Java type options: H2/Derby/SQLite. You may need to change your table structure to include last modified dates and manage those.
Migrate the Access 2 database to SQL Server or another modern, multi-user database.
Including this info here, in case you are able to get to some intermediate version of Access. What won't work as-is:
jackcess & stelsMDB support Access 2000+
HXTT supports Access 95+
Sun's and Oracle's official positions have long been that --
the [JVM-bundled] JDBC-ODBC Bridge should be considered a transitional solution [...] Oracle does not support the JDBC-ODBC Bridge.
However, my employer, OpenLink Software, has produced enterprise-grade commercial Type 1 Bridges between JDBC and ODBC since Java 1.0, and these are fully compatible with the current Java 8 and any ODBC standard-compliant driver, including Microsoft's ODBC driver for Access. You can learn more here --
Single-Tier JDBC-ODBC Bridge Driver -- a JDBC driver for ODBC data sources
Single-Tier ODBC-JDBC Bridge Driver -- an ODBC driver for JDBC data sources
A few years ago, JDBC was a little funny in some versions of sqlserver. Is there a "best" jdbc driver out there ? Like, is there a database [suspecting hsql or mysql] that is optimally suited for 100% java development with rdbms ?
Is there a database that is optimally suited for 100% java development with rdbms ?
Nope.
The whole point of a driver is to make an arbitrary database (the one the driver was written for) usable via JDBC.
Oracle has some special tuning for java. I am not sure if that translate to some special facilities for java. My experience is that first we pick a database and a suitable driver. Then we live with whatever the driver offers.
I used jtds to connect to MS-SQL without any problems. (well, my programs just query and update relatively simple structures)
Do we always have to use jdbc with Java programs for making connectivity with database or can we use only odbc for connecting to databases with Java programs?
Sun JRE contains a built-in JDBC/ODBC driver (sun.jdbc.odbc.JdbcOdbcDriver). Here's an example how to use it: http://www.javacoffeebreak.com/articles/jdbc/
The driver was removed in Oracle JRE 8, so use Java version 7 or earlier.
You can't use ODBC directly because your JAVA program needs to use the JDBC driver to interact with the Database.
As others have mentioned you can use the JDBC/ODBC bridge driver. (Repeating #Rustam's link here: http://www.javacoffeebreak.com/articles/jdbc/).
There are a couple things to keep in mind when using the JDBC-ODBC bridge. First: it's use was not recommended by Sun for various reasons. The top three implications of using the bridge instead of a proper JDBC driver are:
Not every feature of JDBC is supported. ODBC is a more restrictive API, so some features (like savepoints in transactions) are not supported. However, the most common features like prepared statements are.
The native code to Java runtime translation is much slower than if you were doing everything in Java.
The JDBC/ODBC driver is more fragile than the appropriate JDBC driver. Essentially, if implementers of the ODBC driver don't do things a certain way, the JDBC driver will fail and throw some extra exceptions you might not be able to catch. In particular, you will be more susceptible to memory leaks. If you aren't building a long running service you might be OK.
That said, the JDBC/ODBC driver will work for a database that does not have direct JDBC support (most major databases do). Sometimes you don't need all those fancy features and just want to throw something together quickly. The JDBC/ODBC driver is designed for that.
Short answer : NO.
ODBC ( Open Database Connectivity ) hides the details of what database you are talking to. It has nothing to do with Java. If java programs need to talk to the database, then they have to interact with ODBC drivers. To interact with ODBC drivers, you need JDBC-ODBC drivers which hides the details of how the communication happens. You can pretty much make a few method calls and all set to go. The power of abstraction.
You can use JDBC-ODBC drivers
My understanding is that you would not want to - it would become tedious and error prone when things dont go perfectly.
I.E. you can't catch an exception when/if you invoke a non java DLL from inside java.