Background
It may happen that the timeSensor Client no longer finds its server after an update, or that customers land on a test server on the same network when the productive server is turned off.This article discusses how 4D behaves in this regard.
Order
After starting the 4D client, it needs the IP address of the database server. 4D behaves at this point as follows:
- Pressed Alt key - Show connection dialog
- Read EnginedServer.4DLink - if a valid server address is entered, connect to the server
- Polling: the client searches in the current subnet to see if he finds a suitable server. If so, it automatically connects to the server
- read lastServer.xml: if nothing can be found in the subnet of the client, the client searches for the lastServer.xml file. The last server used is entered there - if a valid server address is entered, connect to the server
- Not a valid server found - Show connection dialog
This order causes the client to land on the wrong server after an update if the server broadcasts its address and no valid server is entered in the EnginedServer.4DLink file.
Workaround
Unfortunately, since we cannot change this behavior with programming measures at least at short notice, we would recommend that you stop broadcasting of test servers.
This is possible by blocking the UDP protocol on port 19813 in the firewall of the test server.