When the 1432 Client-Server connection failure is limited to all local and remote connections 1. The Database License The database server will accept only local logins when a Personal Database, or the embedded personal RDBMS with Development Licenses like 4GL Development, OpenStudio/Provision, PDSOE is in use.
Local client's can connect Client/Server when the Personal Database is started with -H localhost, refer to Article:
For remote client's, either an Enterprise or WorkGroup license will need to be used to start the database
2. Multiple-Databases When more than one database is connected, assure:
- All databases are started multi-user. Typical use-cases include longer startup times of one database due to bi recovery processing before client's can connect, or one of the databases is in the process of or has shutdown.
- The database contains an Auto-Connect list with parameters that no longer match those the database was started with. Refer to Article Error 1432 with errno 0 due to auto-connect record in database [000149671]
When the 1432 Client-Server connection failure is limited to certain remote connections 1. FirewallA firewall between the client machine(s) and the database server will cause error 1432 or eventually
"No more servers available". Verify the existence of an active firewall and then the firewall rules:
- On the client machine
- Between the client machine and the database server
- On the database server
Review the port configuration for each database.
Assure firewall rules allow the 3-way handshake to complete:
2. Network cards with Receive Side Scaling (RSS) enabledSpecific to Windows environments, RSS causes intermittent client/server connection issues. Refer to Article:
3. TCP/IP configuration issues a. Client/Server Database Startup parameters
Remote servers are known to not function properly when spawned on a port in the configured -minport -maxport range that are reserved in the /etc/services.
Configure "-minport ; -maxport database startup parameters to use this unreserved range.
While this parameter will not prevent 1432 errors, it will assist with removing pending connections in order that those clients that can connect still have connection slots available. Refer to Article:
b. IPv4 vs IPv6
Since OpenEdge 10.1C, when the database broker is started for IPV6, the hostname (or IP address) is not ignored. The Broker will monitor the IP address supplied by the -H parameter and all servers started by the broker will monitor the same IP address.
As a consequence, when connecting over IPv6 without the IPV6 flag (
-ipver IPv60 in the connection string (or .PF file), the connection will fail with error 1432. For further information refer to Article:
c. Differences between the:
hostname <> IP <> NIC If the database is started with the -H parameter and an Enterprise or WorkGroup license is installed, remove it from the startup parameters and restart the database or use a test database.
When to use machine-name or IP address or localhost for the value of the connection parameter -H [000010719]Starting with Progress 9.x:
- -H can use the IP address instead of the hostname
- -S can use the the port number instead of the service name
Example:
The database is started on the host (IP address 192.10.14.2):
There is no -H parameter used to start the database
$ proserve <dbname> -S 5678
Connect the client with the IP Address and Service port number:
$ pro <dbname> -H 192.10.14.2 -S 5678
If the connection succeeds by using the IP address and port Number instead of the hostname and service name, on both the client and server machines:
- Review the services files (etc/services) to ensure that the servicename that is usually specified with the "-S" parameter when starting the database, maps to the same port number on both machines.
- Check the IP address in the DNS configuration matches the hosts files (etc/hosts)
- Check the and DNS to ensure that the hostname used with the -H parameter resolves to the correct IP address of the server machine where the database is running, from the client machine. Hostname must be the alias of IP number of the server machine where the database is started.
If the connection fails when using the IP address and port Number
- Verify the port Remote Servers are listening on and available connection slots available (-Ma). How to use PROMON to find the port used by the database broker at startup [000021360]
- Connect the client directly to a spawned remote server. Example: Where 3000 is the port a remote server is listening on with available remote connection slots. make a direct connection bypassing the Broker:
$ mpro dbname -S 3000
If this succeeds the issue is between the database login broker sending the remote port number back to the client, which is then timing out with 1432.
Contact the Network Administrators to assist with analyzing the output of non-Progress utilities to assist in diagnosing where in the 3-way-handshake the connection is failing:
Examples: "tracert", "pathping", ipconfig /renew, ipconfig all, telnet, ftp get filename, wireshark
Otherwise please open a Technical Support call in your region (via Phone or directly with your SupportLink credentials) providing the appropriate evidence relating to your situation so that we may assist you further.
5. Check Ports and Hostnames used in PF files.
Check the ports used by the database server to make sure they match with the port numbers or names used by the client within the client startup parameters or PF file.
Check the IP or hostname used by the database server to make sure they match with the IP or hostname of the machine which is being connected to.
The parameters may have been changed either for the database startup or the PF file but these must agree to allow the client to connect to the database(s).
