Chapter8.Server Agent Administration
Abstract
Guide for successfully installing and running the OpenLink server components from the OpenLink Multi Tier Data Access Suite. This chapter describes the roles of the OpenLink Database/Service Agents and how to configure them. OpenLink Server Agents come in two main types, the Database agent and the Service agent. Database agents provide the only database dependant component, usually requiring a separate agent per database major version to connect to. Service agents provide other services such as proxying of connections or special interfaces to other ODBC data sources.
Table of Contents
- 8.1. Administration Assistant
-
- 8.1.1. Wizard Based Administration
- 8.1.2. Forms Based Administration
- 8.2. Agent-Specific Settings
-
- 8.2.1. Common Agent Configuration Options
- 8.2.2. Virtuoso
- 8.2.3. Informix
- 8.2.4. Ingres
- 8.2.5. Progress
- 8.2.6. Oracle
- 8.2.7. Sybase
- 8.2.8. Microsoft SQL Server
- 8.2.9. TDS
- 8.2.10. DB2
- 8.2.11. PostgresSQL
- 8.2.12. MySQL
- 8.2.13. OpenLink ODBC Agent Installation & Configuration
- 8.2.14. OpenLink ODBC-JDBC Agent Bridge Installation & Configuration
- 8.2.15. OpenLink Proxy Agent
- 8.3. Database Configuration for Unicode
-
- 8.3.1. Oracle 8 & 9
- 8.3.2. Informix 9.x
- 8.3.3. Sybase 12.5 +
- 8.3.4. Progress 9.1 (SQL-92)
- 8.3.5. DB/2 v7.x
- 8.3.6. MS SQLServer 2000
- 8.3.7. Operational Notes
- 8.4. Obtaining Agent Information
-
- 8.4.1. Specific Agent Information
- 8.5. Linking OpenLink DB Agents
-
- 8.5.1. General Linking Approach
- 8.5.2. Relinking Progress Agents
- 8.6. Progress Troubleshooting & Advanced Configuration
-
- 8.6.1. OpenLink Data Access Components
- 8.6.2. How OpenLink's Data Access Drivers Connect To Your Progress Database
- 8.6.3. Initial Connection Problems
- 8.6.4. Making OpenLink Database Agent Use a Sockets Based IPC
- 8.6.5. Distributed Databases, Array Fields, Database Triggers
- 8.6.6. Using OpenLink ODBC, Progress & Microsoft Access
- 8.6.7. Key Microsoft Access Jet Engines Setting That Can Affect Your OpenLink ODBC Experience
- 8.7. Application Server Architecture
OpenLink Database/Service Agents are the only database specific components within the OpenLink Multi-Tier middleware framework. It is these components that actually initiate and maintain database sessions with your OpenLink Clients, basically playing the role of a data access server.
Database Agents are servers implementing client data access interfaces such as ODBC, JDBC, UDBC, and OLE-DB using the lower level native call level interfaces provided by each supported database engine. These call level interfaces are themselves increasing based on the X/Open SQL Call Level Interface (CLI) specification. The older database engines that do not support or implement the X/Open SQL CLI specification simply provide traditional Embedded SQL interfaces.
The fact that Database Agents are built using natives interfaces provided by database engine vendors has some very important implications:
-
Through the eyes of a backend database, a database agent is a database client, no different to any other native client provided or bundled with the backend database engine.
-
A database agent inherits all of the functionality of a traditional database client, this includes: Distributed Database, SQL syntax, Stored Procedure support, and anything else that may be specific to the relevant backend database engine.
-
Configuring a database agent is no different to configuring an native database client, they share operating system environment variable dependencies etc..
-
Resource utilization is identical to resource consumption for native clients, this means that if you have special setting for your native client sessions, you will be able to apply these when configuring your database agents.
-
Any efficiencies or deficiencies in the database engines CLI client to database server inter process communications (IPC) also affects a database agent.
All database engines operate under a client-server paradigm, that is to say there are always two distinct processes involved in a database session, the database server and the database client. The database server must be up and running before a database client can communicate with a database. Database client and server processes may or may not reside on the same physical machine, at the same time this has no bearing on the fundamentals of database client and server process interaction as just explained.