You can TL/DR to the end of the post.
I know that “automatic data file switch” is possible since v15/R4 (I performed several demos in public), but in my case, I was using a “default data” folder (v15) as well as the “Use new architecture for application deployments” option (15 R4).
In your case, it sounds like you are trying to game the system by creating a data file, opening it, then deleting it. None of that is necessary, but it isn’t forbidden to do it that way either.
So let’s try to decipher the documentation.
- “4D tries to open the last data file opened”
How does 4D remember the “last data file opened”? It is written in the structure file, or in an external file if Use new architecture for application deployments is activated. The external file has 2 possible locations in v17, 3 in v18. What is the situation in your case?
For merged applications, the data linking mode also has an effect.
- “4D tries to open the data file in a default data folder”
It seems like you don’t have a “default data” folder, so we can skip this one.
- “4D tries to open the standard default data file”
This is where we have an issue, right?
Historically, options 1 and 2 didn’t exist, so what the documentation is trying to suggest is that we default to the “old (pre-v15)” behaviour.
In general, 4D would indeed look for a data file that is synonymous and adjacent to the structure file, if a data file has never been opened before.
If you have already opened or created a data file, its absolute path is stored in the structure file and 4D will understand that it should not use the data file that is synonymous and adjacent to the structure file. If the stored data file path is invalid, 4D would prompt a “where did you move my data file!!!” dialog. This is the behaviour you are seeing right now.
When the first data file created or opened is in fact placed next to to the structure file, its relative path (./name.4DD) instead of an absolute path is written in the structure file.
Storing the relative path (I should probably say, the path name, since I don’t think …/ is supported) worked well for non-merged applications because it allows you to move the database folder to a different location and 4D can always find the last opened data file.
For built applications, this behaviour can cause problems.
First, every time we do an application build, the structure file has no record, relative or absolute path, of a “last opened data file” (note: there is a build key for that, but not exposed in the wizard). Second, one could “imprint” a relative data file path in a freshly built structure file in order to avoid the “create or select” dialog, by manually creating or opening a data file that is next to the 4DC, but that path would invalidate the data file chosen by the end-user after a structure update.
That, I assume, is what triggered the creation of the complex system that we have since v15.
But that is now history.
Going back to your post:
The very first line in your quote from the documentation is
The opening sequence for launching a merged application is…
Q. is your server application a merged application?