How CONNX Works

The CONNX Administrator and CONNX client components are installed on a selected computer, usually designated as the CONNX Administrator computer, although the components can be installed on more than one computer. Installation of the CONNX client provides an interface between the end-user application and databases of several different types and platforms. However, to the end user the databases, tables, joins, views, and other database elements appear as if all the various data sources are a single database.

DB2, Oracle, SQL Server, PostGres, MySQL, Sybase, Informix, OLE DB Enterprise, OLE DB Desktop, DataFlex, and POWERflex databases do not require a CONNX server component.

The relational data sources Oracle Rdb, Oracle, SQL Server, Informix, Sybase, Adabas, and PostGreSQL are supported on Windows and Unix systems.

C-ISAM, DISAM, and Micro Focus install a server component on the UNIX server. There are also Windows-compatible versions.

The CONNX OLE DB and ODBC server component resides on the client machine. It uses the OLE DB or ODBC driver that exists on the client machine. The CONNX OLE DB server component is automatically installed when required.

OLE DB is not supported when CONNX is run on a non-Windows client machine. In such cases, a third-party ODBC driver manager can be used.

CONNX has a distributed SQL engine, which means that the work of processing queries is distributed between the client and the server. Most of the CPU-intensive query processing, such as data conversion and sorting, is performed on the client computer. All of the data retrieval is performed on the server, although, in CONNX for DataFlex, all processing is done on the client computer.

The CONNX distribution of labor, except that for DataFlex, is shown in the following table:

Client	Server
Data conversion	Indexed retrieval
Metadata retrieval	Non-Indexed retrieval
First pass SQL optimization	Joins
Joins	Data compression
Sorting	RPCs
Grouping	Database security
Extended SQL functions
CONNX securtity

This distributed architecture has several advantages:

When performing joins, significantly less data is sent across the network because no duplicates are transmitted.

The workload on the server is minimal, because CPU-bound tasks are moved to the client, resulting in a reduction of load on the mainframe.

When several users are issuing queries simultaneously, the CPU power of each client computer is utilized in addition to that of the server, resulting in true parallel processing. This makes CONNX highly scalable to a large enterprise.