Try OpenEdge Now
skip to main content
DataServer for Microsoft SQL Server
Additional Features to Enhance DataServer Performance

Additional Features to Enhance DataServer Performance

For configuration purposes, the server component of the DataServer can be a distributed “client/server” or non-distributed “self-service”. Progress recommends running a “self-service” DataServer if there is no specific reason to distribute the components of the DataServer. This avoids Progress networking protocol and the extra network hop between the client and server component systems on different machines. Network bandwidth can be a limiting factor when database access includes large data transfers.
A DataServer for MS SQL Server session can be established from either the OpenEdge AppServer or the Progress AppServer products. DataServers distinguishes between the OpenEdge AppServers and Progress AppServer based on the use of threads versus processes when establishing the agent for the DataServer session. Both AppServer environments require access to a schema holder database from which a logical database can be connected.
The Progress AppServer environment does not provide a broker facility from which the server component of the DataServer can be spawned. It only runs DataServers in “self-service” mode. Self-service mode is the most efficient way to establish a DataServer session from an AppServer and it is the preferred configuration for DataServer access in terms of performance.
The Progress AppServer runs all the DataServer sessions from agents in a single process space and avoids the context switching and communication between processes of the traditional AppServer and the Progress AppServer can provide a significant reduction in overhead by multi-threading the DataServer sessions. Progress recommends use of the Progress AppServer over the OpenEdge AppServer for better DataServer and OpenEdge performance.
Progress also recommends using a shared schema holder database between agent processes of the traditional AppServer or agent threads of the Progress AppServer. By sharing a logical database from a common, read-only, schema holder between AppServer agents, a DataServer session gains access to the same foreign data source for many agents using a single common schema.
Note: This assumes all clients connected through the AppServer want access to the same version of the logical database. Otherwise, multiple logical databases may be required which can also be shared from one or more shared schema holder databases. Progress recommends a schema holder be connected “self-service” in read-only mode using shared memory for better performance since it will not have the overhead of Progress networking.
There are a variety of additional DataServer-related features you can employ to enhance your DataServer's performance.
* Enhancements overview
* Connection pooling
* OpenEdge query types
* Query tuning
* Caching records
* Join by SQLDB
* Writing queries for performance
* Modifying the run-time schema check
* Replacing FIND FIRST for performance