JDBC drivers load into an emulator that transparently starts in the background of your machine (if it is not already running) whenever an application connects to a SQL database. While not ideal, that is no problem if the application itself is written in Java! But some risky strategies have emerged that configure native (non-Java) applications like Excel or FileMaker Pro to activate the Java emulator on Macs and Linux for the sole purpose of using JDBC drivers to connect with a database server. This "connect to the database server by any means" strategy is like launching VirtualPC, but is much more incideous because it happens "behind the scenes" and out of your control. That is, the Java emulator immediately consumes RAM, CPU cycles and disk I/O bandwidth from your other applications, including the one you are using to process the data arriving from the database server. The impact is most noticable on mobile computers (laptops, smartphones, etc.) which typically have slower memory busses, lower speed storage/drives and limited CPU power when operating on batteries or in hot environments. It is also noticeable on Linux boxes serving web pages with less RAM and smaller CPU caches. The vendors of the JDBC "plug-ins" intended them to be used only with Java applications and therefore they dont mention the devistating impact of launching Java on your notebook or webserver if you are not otherwise using Java. It is one thing for Java applications to use native ODBC drivers (via the free JDBC-ODBC Wedge), but it borders on dishonesty for certain third-parties to sell so-called native ODBC drivers that do nothing but fire up the Java emulator and pass the requests into JDBC drivers.

It also should be noted that even among the few vendors that write JDBC drivers, none seem to keep them feature-compatible and on the same schedule as their native Windows ODBC drivers. As a result, database servers upgraded due to security and bugfixes, may develop conflicts between their up-to-date Windows clients and less-up-to-date JDBC drivers (or other non-Windows ODBC drivers), leading customers to make hard choices. For these reasons, we built ODBC ROUTER to tie all non-Windows platforms into all databases through the Windows ODBC drivers and only recommend using JDBC with actual Java applications and only then, when also used with the free "JDBC-ODBC wedge" that enables Java applications to use fast/native ODBC drivers.

ODBC ROUTER is all native code --there is no capacity-reducing Java emulation going on and ODBC ROUTER cleanly interfaces native applications (like Apache, Excel, FileMakerPro, PERL, etc.) with database servers via their officially supported Windows ODBC binary interface (even if those databse servers are located on remote mainframes, Unix boxes or Macs).

"Mac, Linux and Windows applications make efficient binary calls to ODBC. Next, the ODBC ROUTER transparently passes those calls (in binary form) to the database server's official Windows ODBC driver (on a Windows Server). Finally, ODBC ROUTER returns any results to the client application (in binary form). Each entire cycle operates with system-level efficiency."

ODBC ROUTER does not emulate proprietary client/server protocols used between the database server and its Windows client as FreeTDS and other unsound "wire-level" solutions do.

ODBC ROUTER also does NOT require the server to do any per-transaction data-transformations or produce a spreadsheet (XML) document after each query. Instead, ODBC ROUTER uses a high-performance network transport that is the result of three years of development. This allows ODBC ROUTER to deliver faster response-time and more server capacity than competitive offerings can provide.