Why Do I Need To Pay For ODBC, JDBC, ADO.NET, OLE-DB Drivers? (revisited)

Situation Analysis

It's the year 2015, and the fundamental issues associated with the utility of data access drivers remain confusing. Basically, we remain uncertain about the value-to-compensation alignment of ODBC (Open Database Connectivity), JDBC (Java Database Connectivity), and ADO.NET drivers/providers.

Image Image

Why do we pay for anything?

After allowing for consumer irrationality [1], the basis of any payment is fundamentally tied to the monetization of opportunity costs. Essentially, we pay for one thing to alleviate the (usually higher) costs of something else.

The rest of this post focuses on highlighting the real pains associated with the $0.00 value misconception associated with Data Access Drivers: ODBC, JDBC, ADO.NET, OLE-DB, etc.

Real Costs of Data Access Drivers

In the most basic sense, there are some fundamental aspects of data access that are complex to implement and rarely implemented (if at all) by free drivers. The list includes:

  • Escape Syntaxes for Dates and Functions -- abstraction for dates and function signatures at the application level (i.e., the same abstraction works across all compliant databases)
  • Metadata Calls which enable smarter ODBC compliant applications -- this feature is typically missing in Drivers and abused by the Clients (consumers); i.e., clients are made DBMS specific by testing for specific DBMS names, rather than utilizing feature and functionality metadata returned by drivers
  • Scrollable Cursors -- this is how you deal with change sensitivity and paging through large datasets; some drivers actually fake support and get away with it due to shortage of applications to test proper cursor types (Static, Forward-Only, Key-Set, Dynamic, and Mixed models).

Beyond actual driver sophistication, in regards to key feature implementations, let's up the ante by veering into the area of data security. At the most basic level, It's extremely important to understand that all data access drivers provide read-write access to your databases; thus, it's imperative that data access drivers address the following:

  • Read-Only or Read-Write Access modalities scoped to specific
    • users
    • user groups
    • target databases
    • data access standards (e.g., ODBC, JDBC, ADO.NET)
    • client applications
    • client host operating systems
    • client host IP addresses
  • Any combination of the above as part of a configurable collection of data access rules (or policies).

Once you're done with security, you then have the thorny issue of data access and data flow management. In a nutshell, your driver needs to be able to handle:

  • Protection against Cartesian-product-based network flooding (e.g., user queries an enormous table without knowing or understanding back-end implications)
  • Enabling or Disabling of key DBMS engine data access optimization features (e.g. SQL RDBMS-specific extensions exposed via Environment Variables or SQL-command-based settings)
  • Conditional Connection Pooling across various dimensions such as Users, User Groups, Applications, Host Operating Systems, IP Addresses
  • Encryption of Data in Transit

Once you've dealt with Security and Data Flow, you then have to address the enforcement of these settings across a myriad of ODBC compliant host, which is where Zeroconfig and centralized data access administration comes into play i.e., configure once (locally) and enforce globally.

OpenLink Universal Data Access (UDA) Drivers

When OpenLink Software entered the ODBC Driver Market segment (circa 1992), the issues above were the fundamental basis of our Multi-Tier Drivers. Although the marketplace highlighted our drivers for high performance, stability, and specification adherence -- to all of which we remain committed -- our fundamental engineering focus has always been skewed towards configurable data security, platform independence, and scalability.

Every item of concern outlined in the section above is addressed by security features built into our Multi-Tier Drivers [2][3][4]. These features all leverage the fact that our multi-tier drivers include a sophisticated DB session rules book that enables construction and enforcement of user attribute (user name, application, client operating system, IP address, target database etc.) based rules which are applied to all database sessions (single or pooled).


Today, in the year 2015, the security issues that pervade Data Access, whether via Native SQL RDBMS Drivers, or ODBC, JDBC, and ADO.NET Drivers/Providers, have only increased, courtesy of ubiquitous computing -- facilitated by the Internet & Web, across desktop and mobile device dimensions. Paradoxically, there remains a fundamental illusion that all Data Access Drivers are made the same; i.e., they simply provide you with the ability to connect to SQL RDBMS back-ends, for the industry standard price of $0.00, without consequence -- thereby skewing the very nature of SQL RDBMS data access and its security and privacy implications.

I hope that this post brings some clarity to a very serious security and general configuration management issues associated with Data Access Drivers. Free ODBC Drivers offer nothing; that's why they cost $0.00. When dealing with real issues associated with Open Data Access, you must have a handle on the inevitable issues of data security and privacy.


  1. The Irrational Consumer: Why Economics Is Dead Wrong About How We Make Choices
  2. OpenLink Multi-Tier ODBC Drivers
  3. OpenLink Multi-Tier JDBC Drivers
  4. OpenLink Multi-Tier ADO.NET Providers


# PermaLink Comments [0]
06/11/2015 17:18 GMT-0500 Modified: 07/17/2015 14:00 GMT-0500
Life after sun.jdbc.odbc.JdbcOdbcDriver

In the beginning...

When Sun originally released Java 1.0, there were no JDBC drivers -- there wasn't even a JDBC.

Data access came in Java 2.0, as JDBC 1.0, but there were very few JDBC drivers from any source, as would be expected with any new technology -- but the ODBC ecosystem (itself then at only v2.0) was going strong.

Sun recognized that Java wouldn't have as much uptake without a functional data access solution -- so they produced and bundled the original Type 1 JDBC-ODBC Bridge Driver, sun.jdbc.odbc.JdbcOdbcDriver, but from the very beginning, they warned that users "should use the JDBC-ODBC Bridge only for experimental prototyping or when you have no other driver available."

That bundled JDBC-ODBC Bridge was (and always remained) single-threaded, and though it received some other updates along the way, it only ever supported a subset of JDBC 2.0 and later. Sun (and later Oracle) recommended that users employ "a pure Java JDBC technology-enabled driver, type 3 or 4, in order to get all of the benefits of the Java programming language and the JDBC API."

Where does OpenLink Software come in?

Even in the early days of JDBC, we saw that there would not always be an available JDBC driver for a given target data source -- but the numbers of ODBC drivers were rapidly increasing, supporting every major and many minor DBMS and other data sources. We saw a need for an enterprise-grade, non-experimental Bridge solution, with full support for the JDBC API.

We delivered this first as our Type 3 Multi-Tier solution, bridging from JDBC in one environment (typically a UNIX-like OS) to ODBC in another (most often, Microsoft Windows).

Type 3 Enterprise Edition (Multi-Tier) Architecture Diagram
Type 3 Enterprise Edition (Multi-Tier) Architecture Diagram
(click to enlarge)

Soon afterward, we released our first Type 1 Single-Tier solution, first for Windows, but quickly also supporting Linux, Mac OS X, Solaris, AIX, HP-UX, and other UNIX-like OS, through our own iODBC driver manager -- which was itself helping to expand the ODBC ecosystem far beyond its birthplace on Windows.

Type 1 Lite Edition (Single-Tier) Architecture Diagram
Type 1 Lite Edition (Single-Tier) Architecture Diagram
(click to enlarge)

Why is Java 8 so special?

Sun long warned that the JRE-bundled Bridge was transitional, and Oracle confirmed immediately upon acquisition that it would "be removed in JDK 8. In addition, Oracle does not support the JDBC-ODBC Bridge." Java 8 is now in full release, and indeed, the venerable sun.jdbc.odbc.JdbcOdbcDriver is no longer present, as evidenced by the scary looking error --

java.lang.ClassNotFoundException: sun.jdbc.odbc.JdbcOdbcDriver
    at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:30
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:259)

Any Java users or applications relying on ODBC connections and also needing the security and other improvements found in Java 8 are left high and dry... Or would be, but for OpenLink Software.

Our JDBC-to-ODBC Bridge, in both Type 1 and Type 3 forms, has been available and regularly updated since its original release for JDBC 1. Fully multi-threaded since Java Runtime Environments (JREs) could handle such, we have also kept pace with the JDBC API -- now at JDBC 4.2, in 2015's Java 8 a/k/a JDK/JVM/JRE 1.8 -- and maintained compatibility with the also-evolving ODBC API, now at 3.8.

Especially important for the modern world, our solutions support both 64-bit and 32-bit environments, including both 64-bit JVMs and ODBC drivers, and our Type 3 solutions can even bridge between these, whether you have a 64-bit JVM and need to connect to a 32-bit ODBC driver, or you have a 32-bit JVM and need to connect to a 64-bit ODBC driver.

As always, our solutions are available for immediate download, with a free two-week trial license provided alongside. We encourage pre-purchase installation, configuration, and testing, with support provided through our web-based Support Forums and even free up-and-running Support Cases. Once you've confirmed the driver works for you, entry level and special offer licenses may be purchased online or through our Sales Team; these as well as custom license configurations or partnership (IBP, ISV, VAR, OEM, etc.) arrangements are always available by direct contact.

# PermaLink Comments [0]
06/04/2015 17:12 GMT-0500
22023DT013: Mixed timezoned and timezoneless arguments in datediff
        __01 => 'second',
        __02 => (DATETIME value, tag 211),
        __03 => (DATETIME value, tag 211),
        SELF => reference 0x7f7c200e61c8 to instance 0x7f7c2061c5f8 of DB.DBA.page_2586a52d45e2079afbb5169d58681d302_templates_openlink_index_vspx,
     control => reference 0x7f7c205ac678 to instance 0x7f7c2098b4c8 of DB.DBA.vspx_row_template,
        SELF => reference 0x7f7c205ac678 to instance 0x7f7c2098b4c8 of DB.DBA.vspx_row_template,
        __01 => 289195288,
        __02 => 19,
        __03 => reference 0x7f7c205ac678 to instance 0x7f7c2098b4c8 of DB.DBA.vspx_row_template,
        SELF => reference 0x7f7c200e61c8 to instance 0x7f7c2061c5f8 of DB.DBA.page_2586a52d45e2079afbb5169d58681d302_templates_openlink_index_vspx,
     control => reference 0x7f7c20a028d8 to instance 0x7f7c2062c0c8 of DB.DBA.vspx_template,
        SELF => reference 0x7f7c20a028d8 to instance 0x7f7c2062c0c8 of DB.DBA.vspx_template,
        __01 => 289195288,
        __02 => 19,
        __03 => reference 0x7f7c20a028d8 to instance 0x7f7c2062c0c8 of DB.DBA.vspx_template,
        SELF => reference 0x7f7c22c48dd8 to instance 0x7f7c20a03e48 of DB.DBA.vspx_data_set,
     ct_name => 'template2',
        __01 => 305595560,
        __02 => 21,
        __03 => reference 0x7f7c22c48dd8 to instance 0x7f7c20a03e48 of DB.DBA.vspx_data_set,
        __04 => 'template2' in v:data-set "posts" (render)
Powered by OpenLink Virtuoso Universal Server
Running on Linux platform