Open Database Connectivity Router
White Paper
Table of Contents
AUGSOFT’S Open Database Connectivity Router (ODBC ROUTER)
Non-Windows
ODBC Driver Managers
About the Open Database Connectivity (ODBC) Standard
AUGSOFT’S
Open Database Connectivity Router (ODBC ROUTER)
AUGSOFT has extended the Open Database Connectivity system used by most office applications to communicate with most database systems by offering users two new routing components that enable all of their database-specific drivers and supporting libraries to be installed only once, on a cental Windows Server, where they are transparently available to any Macintosh, Linux or Windows system in their network. That is, the new ODBC ROUTER solution permits a single set of database-specific client software to support an entire network of customer laptops and non-Windows systems, thereby eliminating the need for that software to be purchased and maintained for every machine. What's more is that because all applications connect with all databases using a single set of drivers, each user will see the same consistency regardless of whether they are using MacOS, Linux or one of the various releases of Windows.
As shown below, AUGSOFT’S free OverDriver™ is installed on all desktops, laptops and web servers in place of any other ODBC drivers. AUGSOFT’S low-cost ODBC ROUTER then transparently processes application requests arriving from client-side ODBC Driver Managers against the System data sources defined in the ODBC Control Panel of the Windows Server.
Comparison
of Traditional ODBC vs. AUGSOFT ODBC Solutions
ODBC on Macintosh and Linux
Database Drivers
One of the primary issues faced by database users on non-Windows platforms is that the selection of available ODBC drivers is not very broad. Despite all of the marketing hype, virtually none of the native drivers work like their Windows counterparts, creating real server problems when used along side Windows desktops. The solution provided by AUGSOFT is our ODBC Router that enables remote access to the wide selection of well-supported ODBC drivers for Windows (such as DB/2®, SQLServer®, Access® and ORACLE®) from both Macs and from Linux webservers.
Non-Windows ODBC Driver
Managers
Another important issue faced by Mac and Linux database users is the problem of selecting the correct ODBC Driver Manager that works with their particular applications.
Mac OS X & Linux
1. iODBC is an ODBC Driver Manager for UNIX that is included with Mac OS X Tiger (10.4), Panther (10.3) and Jaguar (10.2) or is available as a download for Linux and some older versions of Mac OS X Puma (10.1.2-10.1.5). On Mac OS X, AUGSOFT fully supports this driver manager with our new iODBC.NET download. AUGSOFT's Linux download emulates iODBC, so customers do not need to download and maintain it.
2. MacODBC 4.00 is an ODBC Driver Manager that is included in FileMakerPro 6.0 for MacOS X and used by many applications that were migrated from Classic to Mac OS X. AUGSOFT also fully supports this driver manager with our new iODBC.NET download.
3. unixODBC is a "clone" of iODBC that is blindly included in some Linux distributions because it has a KDE extension. We don't like the company behind this product because it infringes on domain names of the company that developed iODBC and our own company. Almost no database companies have delivered support for unixODBC in the several years it has been available so AUGSOFT is unlikely to support unixODBC in the future without a special request. AUGSOFT's Linux download does emulate unixODBC, so most customers need not be concerned with this, even if present on their Linux box.
Classic Macintosh (almost over!)
1. iODBC is an "open source" ODBC Driver Manager for UNIX that was retrofitted for Classic Mac OS in a way that emulates (or at least, attempts to emulate) all of the prior Classic Mac OS ODBC Driver Managers. AUGSOFT now includes this public domain software in a special release of our ODBC OverDRIVER.
2. MacODBC 3.51 is an ODBC Driver Manager for Classic Mac OS included in FileMakerPro 6.0 & 5.5 and Microsoft Office 2001 Update. This driver manager only works with applications that have been specifically designed for it and it can co-exist along side MacODBC 3.11 or MacODBC 3.0.0 (but not iODBC), as desired on Classic MacOS. AUGSOFT fully supports this with ODBC OverDRIVER and recommends it for use with Classic MacOS applications above iODBC, where possible.
3. MacODBC 3.11 is an ODBC Driver Manager for Classic Mac OS created by INTERSOLV and included in FileMakerPro 5.0 for Macintosh . AUGSOFT recommends removal of this driver manager and replacement with MacODBC 3.0.0 (from an MS-Office98 for Macintosh CD-ROM) where possible, though AUGSOFT fully supports this driver manager with ODBC OverDRIVER.
4. MacODBC 3.0.0 is an ODBC Driver Manager for Classic Mac OS created by INTERSOLV and included in the Microsoft Office98 for Macintosh product suite. To install this software, users need only check-off "Data Access" and click "Install" within the Value-Pak Installer included on the MS-Office98 CD-ROM. AUGSOFT fully supports this driver manager with ODBC OverDRIVER.
5. MacODBC 2.1.2 is an older ODBC Driver Manager for System 7 that was created by VISIGENIC and is supplied by Apple and third parties for Legacy 68K and older PowerMacs. VISIGENIC is not in business anymore. There are many early versions of their ODBC Driver Manager in circulation, but only the final release 2.1.2 is completely stable and compatible. AUGSOFT now supports this by request only.
6. MacODBC 1.01 is Apple's original ODBC Driver Manager for System 7 and is included with the Microsoft Office 4.x for Macintosh product suite that supports 68K and older PowerMacs. AUGSOFT now supports this by request only.
The rest of this document discusses background information about ODBC...
About the Open Database Connectivity (ODBC) Standard
Now in its third major release, the Open Database Connectivity (ODBC) Standard provides applications with programmatic access to SQL-compatible database systems. ODBC components are now available for Windows, Macintosh and Unix operating systems that permit application developers to write software without targeting a specific brand of SQL database system. This gives end-users great flexibility to match the applications they want with the SQL database systems they use.
ODBC
Components on Desktop 
Platforms
1. One or more ODBC aware applications. Applications such as MS-Office, FileMakerPro or Web-based data access tools such as Lasso, Tango, PHP/FI or Cold Fusion typically enable information to be displayed and updated using a table or form metaphor.
2. An ODBC Control Panel supplied with Windows or on Macintosh (and very old copies of Windows), supplied with MS-Office or FileMakerPro. An ODBC Driver Manager (included with the ODBC Control Panel) links ODBC aware applications with ODBC drivers according to Data Source Names (DSNs) created by the customer in their ODBC Control Panel.
3. One or more ODBC drivers that are purchased (and maintained) to map the ODBC programming standard onto database-specific client libraries.
4. One or more database-specific client libraries that are purchased (from the database vendor) to connect ODBC drivers with proprietary database servers (eg, ORACLE®, SQLServer®, FileMaker) or database files (eg, Access®). [ Note: Some unscrupulous driver vendors have emerged that sell ODBC drivers which connect directly to back-end database servers without going through the database vendor's official client libraries (on either the client or, via an ODBC router, on the server). Sometimes these drivers are referred to as "wire-level drivers" or are sold for as little as $30/copy. In these cases, the driver writer is actually "hacking" into the backend database and their code should be avoided due to the probability that their hack is not correct in all circumstances and will eventually return incorrect data or corrupt the backend database itself. ]
The key strategic advantage gained through the use of the ODBC standard is that organizations are free to change or upgrade their database systems as their needs change without repurchasing or rewriting proprietary applications. For example, ODBC permits seamless upgrades from an MS-Access, FileMakerPro or b-Tree file to a powerful IBM DB/2, ORACLE or Microsoft SQLServer. ODBC can even ease migrations between Microsoft and Unix servers. Note however that during such upgrades, without an ODBC Router, each client machine, that is, each laptop, desktop and webserver in the network, would need updated drivers and database specific client software installed.
ODBC Generations
The ODBC technology has now been through three generations, referred to as ODBC 1.x, 2.x and 3.x. To the application developer and end-user, the functional differences between these generations are not very significant. An ODBC Driver Manager that implements the ODBC 3.x interface is always backwards compatible with all 2.x and 1.x interfaces. Likewise, an ODBC 2.x Driver Manager is always backwards compatible with all 1.x interfaces.
§ The primary benefits offered by the ODBC 2.x generation were to improve the efficiency of underlying ODBC drivers, to clarify certain programming interfaces for driver developers, and to introduce features that make it easier to browse exceptionally large sets of database results. Most of these features are only of importance to ODBC driver developers.
§ The primary benefits offered by the newest ODBC 3.x generation are an improved application and driver-programming interface that streamlines communications between an ODBC 3.x application, ODBC 3.x Driver Manager and an ODBC 3.x driver. However, utilization of this new third-generation interface is only appropriate only for new applications development and does not necessarily provide any additional functionality to existing (ODBC 2.x) applications except insofar as it does support double-byte character sets.
§
Most Windows
ODBC drivers on the market today are developed for the more universally
accepted ODBC 2.x standard and thus an application utilizing the ODBC 3.x
interface will force many ODBC Driver Managers to do additional 3.x to 2.x
conversions between the application and the driver.
ODBC Functionality Levels
Not all database systems have the same level of functionality, yet the ODBC standard enables equal accessibility to these systems under a common programming interface. To keep things simple for users of less functional database systems while still allowing developers to exploit the advanced features of sophisticated database systems, ODBC categorizes its database interfaces into three levels:
§ CORE interfaces represent basic functionality available on all database systems. These interfaces are essential to the flow of communications between an ODBC aware application and an underlying database. All ODBC drivers implement all of the CORE interfaces.
§ Level-1 interfaces represent functionality commonly available in most database systems. Nearly all ODBC aware applications depend upon an ODBC driver having certain Level-1 interfaces and so nearly all ODBC drivers implement all Level-1 interfaces.
§ Level-2 interfaces represent functionality available in only the most sophisticated of database systems. ODBC aware applications cannot depend upon this level of functionality being present in any given ODBC driver and thus, most check for the presence of these capabilities before taking advantage of them. (Nearly everything that can be accomplished using the Level-2 ODBC interface can be accomplished with slightly more programming using the Level-1 interface.)
OLEDB
After extending the X/Open Call Level
Interface (CLI) industry specification to become ODBC, Microsoft’s Data Access
Group went on to create a new technology that would both embrace
object-oriented programming and extend the concept of open data access beyond
the realm of Structured Query Language (SQL) database systems. To this end, Microsoft introduced the OLEDB
standard layered upon its powerful OLE2 (Object Linking and Embedding II)
object paradigm for integrating functionality from disparate applications. But OLE2 requires a Microsoft-proprietary
technology for reusing C++ binary objects (known as COM) and because OLEDB is
layered upon OLE2, OLEDB is unavailable on non-Windows platforms.
OLEDB is a superset technology that may internally use ODBC whenever it needs to connect to SQL database systems. Alternatively, a database system vendor may offer an “OLEDB Provider” module (analogous to an ODBC driver) that interfaces to OLEDB directly, though only a few choose to add this support to their existing ODBC efforts.
Java (JDBC)
Shortly after the release of the Java programming language and Java
Virtual Machine, VISIGENIC (which no longer sells database software or operates
as an independent company) partnered with SUN Microsystems to
bring the same kinds of Open Database Connectivity standards enjoyed by
mainstream users into the Java environment.
To this end, they created the Java Database Connectivity (JDBC)
standard. JDBC so closely mirrors the ODBC standard that a simple “wedge” is
provided that connects JDBC aware applications directly to the ODBC Driver
Manager. AUGSOFT fully supports the
use of the JDBC/ODBC Wedge to enable Java language applications to access ODBC
drivers by way of the ODBC ROUTER system.
About the Java Virtual Machine
However, the term "Java" is used to describe both a high-level language (that can be compiled to Intel, PowerPC, or other machine code) and an unrelated portable runtime system. Through the runtime system, Java language applications can (optionally) be compiled into a SUN defined machine code called "Java Byte Code" (instead of an Intel or other processor's machine code). SUN and others supply a program for many other processors to execute Java Byte Code called a Java Virtual Machine.
Java applications compiled to run on the Java Virtual Machine (as opposed to a physical Intel, PowerPC or other machine) may also utilize JDBC to access ODBC-compatible database systems by way of the JDBC/ODBC Wedge, so long as the target platform has an ODBC Driver Manager.
But the only real reason for compiling a Java language application to Java Byte Code is to achieve portability to every platform that implements a Java Virtual Machine. In the mid-1990s, SUN had a dream that all platforms would support Java Byte Code, thus enabling Java to become a pervasive standard that could challenge the dominance of Microsoft Windows. Unfortunately, it takes much more than a portable binary standard to make portable applications. Each particular platform (Windows, MacOS, UNIX, etc..) has its own strategic advantages in the form of systems software. To make an application that will run portably requires reducing functionality to a Lowest Common Denominator of the system software services found on the various platforms. What's more, since commercial application developers don’t have the ability to know what platforms such applications will be deployed on ahead of time, it is very hard for them to calculate the Lowest Common Denominator and thus ship reliable, highly functional software in Java Byte Code format. Therefore, the Java Byte Code format is best used for “in house” applications where “in house” developers know the capabilities (and specific revision levels) of the various platforms that will actually be used when the application is deployed. SUN has tried to address this by introducing PureJava™ (all Java) system services, but those services are not consistently implemented across all Java Virtual Machines (for example, MacOS 9 and OS/X have radically different support for such services). Therefore, the Java Virtual Machine aspect of Java is of little practical value, especially considering the extensive cross-platform native frameworks available today (Qt3, Tk (Tcl/Tk, PERL/Tk, PYTHON/Tk), GTK, wxWindows, etc...
ODBC ROUTER compatibility with PureJava™
PureJava™ applications are not allowed to access any of the supporting operating system's libraries and thus they cannot use the ODBC Driver Manager or its ODBC drivers, such as the ODBC ROUTER's OverDRIVER. Instead, PureJava™ applications must rely on their own PureJava™ "Type-4" JDBC drivers that run in the Java emulation machine eating local system resources.
AUGSOFT believes that a PureJava™ interface to our ODBC ROUTER is only truly valuable to desktop users running “in house” developed applications (where the Java Byte Code virtual machine environment is most appropriate). But in an “in house” environment, the “in house” developer generally has control over the target platform which negates the need to even create restricted-functionality PureJava™ applications in the first place. Therefore, at this time, AUGSOFT recommends that “in house” Java developers deploy the latest JDBC/ODBC Wedge along with our ODBC OverDRIVER onto their users’ desktops and forego PureJava™ restrictions. That is, compile Java applications into native Intel, PowerPC or other binaries and deploy them onto PCs, CE, Macs and other platforms making use of the full power of the operating systems and hardware your organization is running, without the unrelated virtual machine.
