Database Administratorís Guide


Chapter 2


Although it is not usually a DBAís responsibility to configure network software, you do need to know how SQLBase uses network resources and how to configure SQLBase for various communication options.


SQLBase software consists of both client and server components.

Client-side software is:

ē Applications (like SQLTalk)


ē Communication libraries

ē Database drivers and providers

Server-side software is:

ē Single and multi-user database servers

ē Communication libraries

You can connect a client application to a local or remote SQLBase database. Local means that the client application and database reside on the same computer, while remote means that they reside on different computers.

You run an application and communication library on the client side, and a database server and communication library on the server side. The communication libraries on both sides enable Gupta client applications and SQLBase servers to communicate with each other over a network.

Communication libraries provide network protocol support and specify how an application and a database server communicate. Communication can take place between an application and a database server on the same computer (interprocess communication) or between an application and a database server across a network.

This diagram shows how SQLBase uses communication libraries to connect to the network software.

Local connection

In a local connection, you need only one computer. You run an application and a database server on the same machine. The database server accesses local databases only.

Remote connection

In a remote connection, you need at least two computers because a server and its clients are separate nodes on a network. The client and the server communicate with each other through a protocol such as TCP/IP.

A remote connection: a client and server communicating across a network.

The remote connection depends on your having installed network software on both the client and server computers. You should verify that the network software is loaded and working before attempting to connect a client and server.

Supported protocols

SQLBase supports these network protocols:

ē Anonymous pipes


TCP/IP is the dominant protocol used by SQLBase servers and clients, both on the Windows platform and on Linux. A second protocol, anonymous pipes, can be used on the Windows platform only when both the client and the server components are located on the same physical machine.

Configuring SQL.INI

The main configuration file for SQLBase is usually referred to as SQL.INI. Beginning with version 8.5, that file could actually have any name, but the documentation still uses SQL.INI when referring to the file. (In Linux, which has case sensitivity, the default file name SQL.INI is actually in lowercase.) You will find much more information about other parts of SQL.INI in chapter 3 of this book. For now, this section will discuss SQL.INI only in terms of how communication protocols are implemented in that file.

You configure communication through Connectivity Administrator or by editing SQL.INI directly with a text editor. Through SQL.INI, you control the communication libraries that are loaded, the protocols used, and settings for those protocols.

The file SQL.INI is structured in different sections. This basic structure is the same for both clients and servers (referred to here generically as "platform"). A client or server has a main section:




The names of the platforms are:


Section name




Windows 98, ME, NT, 2000 , XP, or Server 2003



Linux (SQL/API application)

Windows 98/ME and Windows NT/2000/2003/XP servers


All versions (all numbers of users)

Linux servers


All versions (all numbers of users)

Loading communications libraries in Windows

A different section that is named by appending *.dll to the platform name specifies the communication libraries to load.




If you specify two or more comdll keywords in the [*.dll] section, then a client tries each communication library in turn until it finds the database. In the example above, the application first looks for the database locally because sqlapipe.dll is a local communication library. If it is unsuccessful, it then looks remotely, searching the network via TCP/IP because sqlws32.dll is a TCP/IP-specific communication library.

For most of the communication libraries, you optionally have a different section that specifies parameters for the protocol. The section is named by appending the comdll name (without the "sql") to the platform name:




The statements below show the sections for a single user server:












The dbname statement specifies the protocols that a specific database uses for connections. The servername statement specifies protocols available for the server to use. In the example above, the server listens for connections using the anonymous pipes and TCP/IP protocols. The [dbnt1sv.dll] section specifies communication libraries to load when the server starts. In the example above, the server loads the communication libraries for anonymous pipes and TCP/IP when it starts.

The statements below show the sections for a client:











The [winclient32.dll] section shows the communication libraries that the client loads when it first tries to connect to a database. In the example above, the client loads the communication libraries for anonymous pipes and TCP/IP when it starts. The table below shows the name of the communication libraries and the associated comdll statements, the SQL.INI section, and the parameters.



Library name

comdll statement

SQL.INI section



Windows 98, ME, NT, 2000, Server 2003, and XP





Anonymous pipes

Win32 client and server





Handling communications in Linux

SQLBase for Linux communicates only through TCP/IP. Instead of loading separate DLLs, as in Windows, the communication routines are built directly into the database engine (such as dblxsrv) and are handled for clients through component

Despite this fact, the SQL.INI file used on Linux machines will still contain some references to "comdll". Thatís because this string has significance for the low-level communication routines in the database engine and "comdll" acts as a placeholder for those routines when they parse SQL.INI.

Note: We use SQL.INI throughout this book in uppercase, but in Linux this filename would ordinarily be in lowercase.

For the server-related portion of SQL.INI, typical entries would look like this:







The dblxsrv.dll section identifies the protocol and the dblxsrv.tcpip section identifies more specific settings such as the listening port.

The client-related portion of SQL.INI, for Linux applications using, would look similar to this:







The "linuxclient.dll" section is a sort of placeholder to identify the communication protocol (always TCP/IP). The "linuxclient.tcpip" section provides more detail about communicating with specific database servers. If the client application was expected to communicate with several database servers, then there would be several "serverpath" statements in this section. In our example, the server named "server1" located on machine "mymachine" listens on TCP/IP port 2155. The asterisk means that the client can attempt to connect to any database on that server. If we wanted to restrict communication to a single database such as ISLAND, the line would look like:


Remember, SQL.INI can hold lots of configuration information (see chapter 3). We are only looking at entries related to communications here.

Connectivity Administrator

This section shows the basic steps to using Connectivity Administrator to configure communication on client and server platforms. For more about Connectivity Administrator, read the online help.

After you configure SQL.INI with Connectivity Administrator, you can open SQL.INI with a text editor to see the changes.

Note: Currently Connectivity Administrator does not work with SQL.INI files on Linux database servers. You must use a text editor to change such files.

Beginning with version 8.5 Connectivity Administrator allows you to edit a configuration file by any name, in any location. This documentation still uses the name SQL.INI, but your actual file name is under your control. You can have multiple configuration files for multiple clients and servers, and you can tell Connectivity Administrator which file you wish to edit by typing or browsing a file name, as shown in the highlighted text below.

Configuring servers

1. Start Connectivity Administrator.

2. Click the Server tab, if it is not already displayed.

3. Click on one of the server nodes.

4. Expand the Listening Protocols branch.

5. Select a protocol and click the Enable button.

6. With the protocol selected, click the Properties button.

Note: When a protocol is selected, you can also right-click and select from a popup menu to enable a protocol and set its properties.

7. A dialog appears where you can set the protocolís settings.

Configuring clients

1. Start Connectivity Administrator.

2. Click the Connectivity tab if it is not already displayed.

3. Expand SQLBase at the bottom of the list.

4. Select a protocol in the list and click Enable.

5. Click Properties.

6. A dialog appears where you can set the protocolís settings.

Note: After enabling TCP/IP on a client for the first time, you must click Add and fill in the dialog shown below. Connectivity Administrator uses this information to create a serverpath statement in SQL.INI.

When multiple servers are installed on a single computer, and two or more servers are using the TCP/IP listening protocol, it will be necessary to alter the listening port for the servers, as shown above, so that only one is using the default port of 2155, and the others have their own unique port numbers. Remember that port 2156 is reserved for use by the SQLBase Resource Manager.

Anonymous pipes

On Windows 98, ME, NT, 2000, Server 2003, and XP, an anonymous pipe enables clients and database servers on the same computer to transfer information back and forth as if they are reading and writing a file. Anonymous pipes cannot be used across a network.


TCP/IP (Transmission Control Protocol/Internet Protocol) is a collection of networking protocols that have been used to construct the global Internet. TCP/IP is also widely used to build intranets, which are private networks modeled on the same protocols as the global Internet. Intranets, often used exclusively by one organization, may or may not be connected to the global Internet. .

On Windows 98, ME, NT, 2000, Server 2003, and XP, SQLBase uses winsock (Windows sockets) to communicate via TCP/IP. On Linux, TCP/IP communication is part of the server executable, and is handled by on the client side.

If you enable TCP/IP on a client, you must also specify a serverpath statement in SQL.INI.

Database drivers and providers

SQLBase provides industry-standard drivers and providers for client applications to use when communicating with SQLBase. In such cases the client need not be concerned about the specifics of other communication components, only about the correct use of the drivers and providers themselves. These drivers and providers are explained in detail in the book Guide to Connecting to SQLBase. The supported standards are:

ODBC database driver

JDBC database driver

OLE DB data provider

.NET data provider

COM+ and the SQLBase Resource Manager

Beginning with version 8.0, SQLBase transactions in Windows can be integrated into larger COM+ transactions through the use of the SQLBase Resource Manager (SQLBRM). SQLBRM is the component that enables COM+ transactions against SQLBase. It is notified by the Microsoft Distributed Transaction Coordinator (DTC) when a COM+ component initiates a transaction against the SQLBase server. When an application running under COM+ issues a command to commit or abort a transaction, DTC notifies SQLBRM, which causes the command to be executed in SQLBase. If the SQLBase server fails during a transaction, SQLBRM notifies DTC, and later plays back and commits the transaction when the SQLBase server restarts.

SQLBRM.EXE is installed by default as a Windows service. You can run the executable directly instead, but ordinarily you would use it as a service. It takes three parameters:

SQLBRM /ListenPort=2156 /LogDir=c:\windows\temp /Autostart=yes

The values shown are the default values used when SQLBRM is installed as a service (presuming that "windows" is the directory where your Windows operating system is installed.)

The Autostart parameter controls whether SQLBRM will start SQLBase if it's not already running. If SQLBRM is a service, it will start SQLBase only as a service, presuming that SQLBase has been configured to allow this.

Configuring servers and clients

To use SQLBRM with COM+, you must specify the SQLMPIPE protocol in the section of SQL.INI that relates to the database engine:








The SQL.INI settings related to clients require that you use sqlws32 as the communication protocol when running against database engines using sqlmpipe:






Note the use of 2156 as the default listen port for SQLBRM, as contrasted with the default listen port of 2155 for the ordinary SQLBase TCP/IP protocol. This port number must match the port number used when SQLBRM is started.

Shutting down SQLBase Resource Manager

When running as a service, Resource Manager can be shut down from the Windows Services administrator, or from SQLBase Management Console (described below). When Resource Manager receives a request to shut down, it waits until any existing users have disconnected from SQLBase.