When the 1432 Client-Server connection failure is limited to all local and remote connections 1. The Database License
When running Personal Database, 4GL Development, or OpenStudio/Provision licenses, the database server will accept local logins only as all these licenses contain the Personal Database.
Ensure the Database License is either WorkGroup or Enterprise to start the databaseWhen the 1432 Client-Server connection failure is limited to certain remote connections 1. Firewall
A 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:
2. TCP/IP configuration issues
- On the client machine
- Between the client machine and the database server
- On the database server
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 000001603, What is the -PendConnTime parameter?
b. Differences between the: hostname <> IP <> a NIC
If the database is started with the -H parameter, remove it from the startup parameters and restart the database or use a test database.
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
The database is started on the host (IP address 184.108.40.206):
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 220.127.116.11 -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:
Check the services files (etc/services)
Ensure that the servicename that is usually specified with the "-S" parameter 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 by using the IP address and port Number
Verify that Remote Servers are started when connecting and that those processes (by PID) are visible at the Operating System Level. Refer to Article
Connect the client directly to a spawned remote server that still has open connection slots available (-Ma)
mpro dbname -S 3000 (where 3000 is the port the remote server is listening on)
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
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.