Oracle Gateway Promise
Ability to use distributed queries over a generic connectivity gateway (HSODBC, DG4ODBC) -- i.e., to issue SQL queries against any ODBC- or OLE-DB-accessible linked back end.
Reality
Promise fails to materialize for several reasons. Immediate limitations include:
- All tables locked by a
FOR UPDATE
clause and all tables with LONG
columns selected by the query must be located in the same external database.
- Distributed queries cannot select user-defined types or object
REF
datatypes on remote tables.
In addition to the above, which apply to database-specific heterogeneous environments, the database-agnostic generic connectivity components have the following limitations:
- A table including a
BLOB
column must have a separate column that serves as a primary key.
-
BLOB
and CLOB
data cannot be read by passthrough queries.
- Updates or deletes that include unsupported functions within a
WHERE
clause are not allowed.
- Generic Connectivity does not support stored procedures.
- Generic Connectivity agents cannot participate in distributed transactions; they support single-site transactions only.
- Generic Connectivity does not support multithreaded agents.
- Updating
LONG
columns with bind variables is not supported.
- Generic Connectivity does not support
ROWID
s.
Compounding the issue, the HSODBC and DG4ODBC generic connectivity agents perform many of their functions by brute-force methods. Rather than interrogating the data access provider (whether ODBC or OLE DB) or DBMS to which they are connected, to learn their capabilities, many things are done by using the lowest possible function.
For instance, when a SELECT COUNT (*) FROM table@link
is issued through Oracle SQL, the target DBMS doesn't simply perform a SELECT COUNT (*) FROM table
. Rather, it performs a SELECT * FROM table
which is used to inventory all columns in the table, and then performs and fully retrieves SELECT field FROM table
into an internal temporary table, where it does the COUNT (*)
itself, locally. Testing has confirmed this process to be the case despite Oracle documentation stating that target data sources must support COUNT (*)
(among other functions).
The Virtuoso Universal Server will link/attach objects (tables, views, stored procedures) from any ODBC-accessible data source. This includes any JDBC-accessible data source, through the OpenLink ODBC Driver for JDBC Data Sources.
There are no limitations on the data types which can be queried or read, nor must the target DBMS have primary keys set on linked tables or views.
All linked objects may be used in single-site or distributed queries, and the user need not know anything about the actual data structure, including whether the objects being queried are remote or local to Virtuoso -- all objects are made to appear as part of a Virtuoso-local schema.