A practice common in early versions of 4D when building a Client-Server was to include an ad hoc version number in the database name. So a given built client-server could have names like MyDB_001, the next version would be named MyDB_002, then MyDB_003, then MyDB_004, and so on.

This made deployment easy in keeping track with what versions was under development and what version was deployed. One only needed to look at the name of the deployed server to know what version was installed.

The problem with this practice can become a problem, not on the server but on the clients.

With every change of the application name, 4D creates on the client a new cached version of the database structure and all included folders. So for every version that has been deployed to the server there is a cached version of that structure and all included folders on every client that has ever logged on to the server.

If the client platform, real or virtual, runs short of disk space the user will start getting error message like "Unable to sync Plugins Folder" or "Unable to sync Resources Folder." At this point the only cure is for someone to find the cache folder, on Mac the path is "Macintosh HD:Users::Library:Caches:4D:", on Windows the path is "C:\Users\\AppData\Local\4D\" and delete enough of the old cache files to create enough disk space for the current server of install the necessary cache files.

So, the correct practice is to not include any versioning in the database name, instead use the versioning tools available in the Build Application system built into 4D.

The current version of 4D has strongly built in versioning support built into the "Build Applicaiton..." process and should be used, and the Application name should not be changed with each build of the Client-Server application.