4D allows built remote client applications to be automatically updated when a newer client and server is built, and an older version of the client connects to the server.

There are various deployment configurations, which can have the server hosted on various machines with different IP addresses. To make sure the client connects to the correct server there are multiple options availble to apply. The server's IP address can be specified during the build in the build app XML file. The 4D Server can broadcast to the local network and if the client can find it, it can automatiaclly connect to it. A user can also use the Custom Remote Connection dialog to manually enter in the path to the server if enabled.

When a client connects to a server, the last path is stored for subsequent connections to be automatic. This path is stored in different locations based on the architecture of the database applied prior to the build. With the new architecture applied, the path is stored:

On Mac:
/Users/{username}/Library/Application Support/{databaseName}/lastServer.xml

On Windows:
C:\Users\{username}\AppData\Roaming\{databaseName}\lastServer.xml

With a database using the old architecture, the last server path is stored at:
{Client Application Directory}/Database/EnginedServer.4Dlink

As shown, the old architecture stores the last server path with the client applications directory. This can cause issues when performing an automatic update, which replaces the entire client directory, clearing out the last server path potentially causing the reconnection to fail after the upgrade. There are a couple of options to workaround this issue.

For the initial upgrade, the path to the server must be applied somehow. One way is to apply it in the build app XML file another way is to manually modify it in the upgrade files. This is stored at:
{Server Application Directory}/Upgrade4DClient/info.json
In the JSON file, there is a property for the "BuildIPAdress" and "BuildIPPort".
To avoid having to make sure the the path is specified for each machine every time a new build is created, the optimal solution is to move to the new architecture which will make the upgraded application and future upgrades store the last server path with the cache files.