How Entire Access Works

This section covers the following topics:

What is Entire Access?

Entire Access allows client applications running on Windows and UNIX clients to access data sources on Windows and UNIX. The following 64-bit Windows platforms are supported for client and server:

  • Windows 7

  • Windows 8

  • Windows 10

  • Windows 2008 R2 Server

  • Windows 2012 Server

  • Windows 2016 Server

Entire Access under Windows is a 32-bit application and can only access database servers in 32-bit mode. In case the database server is a 64-bit application the 32-bit version of the corresponding database client interface must be installed also.

Data Sources

Entire Access represents a client-server solution for Software AG database systems and for third-party products. The following table lists the data sources for each supported server platform:

Server Data Source UNIX z/OS Windows
Adabas D x   x
DB2 x x x
Informix x   x
Microsoft SQL Server     x
Oracle x   x
Sybase DBLIB x   x
Sybase CTLIB x   x

Entire Access complies with Microsoft's Open Database Connectivity (ODBC) standard. Depending on the products installed at your site, it may be possible to access ODBC-compliant data sources on the same machine and on remote Windows and UNIX server platforms. Whether such access is possible depends on the database system. As a minimum, data sources to be accessed using the Entire Access ODBC driver must comply with the ODBC level 1 API and must accept the SQL core grammar.

General Information on Entire Access

Entire Access supports local and remote databases. It consists of an application program interface (API) and each supported RDBMS driver. Multiple heterogeneous RDBMS can be accessed concurrently from within the same client application.

The API provides a common SQL interface; it receives ANSI-standard SQL requests from the client application and routes them to the driver for the target data source. Entire Access forms the backbone for RDBMS access.

Natural applications use the Entire Access backbone directly. The API supports the use of Natural DML and SQL statements in the same program.

The database driver

  • converts data to ensure consistent data types,

  • emulates RDBMS-specific functions,

  • and automatically coordinates user requests with replies from the RDBMS.

The database drivers are reentrant; thus, after an application establishes a connection to a data source, other applications can access the data source during the same Natural session without having to reestablish the connection.

Accessing Data Sources from Clients

The same procedure is used to access data sources from all Windows and UNIX client platforms:

  1. On the server machine, you start the database and then start Entire Access.

  2. On the client machine, you set the connect string and then start the client application.

Local Data Access

With local access, the application client and Entire Access reside on the same platform as the database server; the Entire Access driver communicates directly with the data source:

graphics/osx_local_data_access_scheme.png

Note:
Both local and remote access to data sources on the z/OS platform are supported by Entire Access. However, local Natural on z/OS does not utilize the local Entire Access API, and therefore z/OS may only be used as a RDBMS server.

Remote Data Access Using TCP/IP

With remote access, application clients communicate with Entire Access on the server side using the TCP/IP communications protocol. Entire Access and TCP/IP must be installed on each client and server machine. The API on the client machine uses TCP/IP to route requests to the database driver on the server machine.

The following diagram shows remote access using TCP/IP:

graphics/osx_remote_data_access_tcpip_scheme.png

Remote Data Access Using Third-Party Network Products

It is possible to use network products supplied by the vendors of third-party RDBMS. The network product for each server RDBMS must be installed on the client and server machines. Entire Access communicates with these network products in the same way it communicates with a local data source. The network product is responsible for transmitting and coordinating the requests and replies between the client and the data source.

There are many possible configurations of RDBMS and third-party network products. Be sure to evaluate a particular configuration to determine whether it will work with Entire Access; if necessary, contact your Software AG representative for assistance. The following diagram illustrates possible uses of third-party network products with Entire Access:

graphics/osx_remote_data_access_3rdparty_scheme.png

Entire Access treats databases accessed through the third-party communications product as local databases. Due to the local illusion implemented by various third-party networking products, Entire Access is completely unaware of the remoteness of the database.

Note that when networking is performed for the client by a third party it is done transparently. It is also transparent to Entire Access, which therefore uses only local connect strings. Because Entire Access is completely unaware of the network rerouting, the local illusion must be completely implemented by the RDBMS vendor performing the networking.

For example, if a local Windows 2012 Server PC is accessing a DB2 on VSE with IBM Connect networking, a local DB2:databasename connect string in Entire Access on the Windows 2012 Server PC is implied. Because Entire Access is completely unaware of the Windows 2012 Server to VSE rerouting, the VSE DB2 syntax must be identical to that of the Windows 2012 Server DB2, with no exceptions.