Testing the Connection with ping - Firebird

All things being equal, the last reality check is to make sure your client machine is communicating with the server host. You can quickly test whether a TCP/IP client can reach the server, using the ping command in the command shell, as follows:

ping server_name // substituting the name you entered in the hosts file

If the connection is good and everything is properly configured, you should see something like this:

Press Ctrl+C to stop the ping responses.

If ping Fails

If you get something like this:

Bad IP address hotchicken

then your host name file entry for the server_name (in this example, hotchicken) may be missing or spelled incorrectly. For example, all identifiers on Linux/UNIX are casesensitive. Another cause might be simply that your server machine’s host name has not been configured.

If you see this:

Request timed out

it means that the IP address referred to in your host name file cannot be found in the subnet. Check that

  • There are no typos in the host name file entry.
  • The network cable is plugged in and the wires and contacts are free from damage and corrosion.
  • The network configuration allows you to route network traffic between the client and server in question. Subnet or firewall restrictions may be preventing the host server from receiving the ping from the client.
  • Subnet restrictions: TCP/IP can be configured to restrict traffic between subnets. If your client machine is part of a complex network of subnets, check with the network administrator that it has unrestricted access to the host server.
  • Firewalls: Your connection test might fail if the database server is behind a software or hardware firewall that blocks port 3050 or your reconfigured port.

Problems with Events

Although each client connects with the server through a single pipe, Firebird events —a callback mechanism that can channel event notifications back to clients from triggers and stored procedures —uses random available ports. On static, self-contained networks without internal firewalls, this usually causes no problems. On networks where there are multiple subnets, dynamic IP addressing, and tightly configured firewalls, the event channels can fail.

In Firebird 1.0.x, your network administrator needs to configure some way to ensure that a port is available that is always free, open, and static. It can be solved in one way or another on most networks.

Firebird 1.5 simplified matters and made it possible to configure an IP address in the network explicitly for events traffic. Use the firebird.conf parameter Remote AuxPort to set statically the IP address of an interface (card, router, gateway, etc.) that is available for event routing.

For more information about Firebird events, refer to Chapter Error Handling and Events.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Firebird Topics