Getting Started






Quick Links











Pooled Processes

Preconnected Processes

Configuration File


ODXNET (Omnidex Network Server) is the client/server listener program that runs as a socket listening process on a UNIX or Windows server, trafficking client requests. ODXNET uses pooled processes to increase connection speed and preconnected processes can also be configured to further improve connection speed.

By default, ODXNET creates pooled processes for each application type (ODBC, JDBC, OmniAccess) automatically when the listener is started. Each client connection attempts to use a pooled process unless explicitly directed through an option to have a new process created.

Each application type comes with a generic application pool that is used by ODXNET. Environment specific application pools can be setup in the ODXNET configuration file for the listener.



Setting up ODXNET varies depending on the operating system and intended use.

  • First, create or modify the ODXNET configuration file. This file contains settings that ODXNET will use at run-time.
    The configuration file should be used in a production environment but can be optionally omitted for a test environment. Most of the required settings have defaults that will be used if the configuration file is omitted. However, some scenarios, such as setting up a Windows NT Service or creating environment specific application pools, require settings that can only be defined in the configuration file.
  • Set the required environment variables.
  • Start the listener process.
  • Set up the client. Omnidex client must be installed on each client machine intending to connect to an Omnidex environment.
  • Test the connection.
    It is always a good idea to test the connection before trying to use a client application with the data source. The Windows client tool DS EDIT is ideal for this.
  • Run the client application.



ODXNET replaced ODXSRVR as of Omnidex version 4.0.

The ODXSRVR listener runs on a specific listener port id, and also uses a range of child port ids. When a client request comes through the ODXSRVR listener, ODXSRVR spawns a child process using one of these port ids, instructing the client to use that port.

The ODXNET listener also runs on a specific listener port id. However, it does not use the range of child port ids. It simply passes a process directly to the client. This method provides some notable benefits:

  • Client connections are faster because the overhead of spawning a new process using one of the port ids is eliminated.
  • In some cases, where the application had a lot of traffic and most of the child port numbers were being used, a conflict occasionally occurred where a child port id was assigned to one client but, because that client could not respond quickly enough, the same child port id was assigned to another client.
  • When connecting through a firewall, the listener port id must be exposed for both ODXNET and ODXSRVR. However, because ODXSRVR actually creates new processes on different ports, ALL of the child process port ids must also be exposed. This is not a problem with ODXNET.
  • ODXNET implements a generic send and receive API which allows for new services to be written that will utilize ODXNET and the NS API.