Data file open order - Bug?

I’m trying to implement an automatic data file switch. To test this I create a data file on the desktop and open it so that it is the default data file link. I then delete it so that it is no longer there, thus making the default link invalid. I have the real data file located else where and would like to programatically change to it. Finally I put a blank data file with the name of the structure file next to the .4DB/.4DC. According to the documentation when rule 1 is invalid and rule 2 is not implemented, rule 3 should be triggered. Meaning the app should open the empty data file allowing the switch. However instead I get 4, the open standard dialog.

Tested with Server and 4D (v17R6 and v18)

I’m thinking this is a bug unless I’m missing something. Has anyone else tried something like this?

Opening the data file

When a user launches a merged application or an update (single-user or client-server applications), 4D tries to select a valid data file. Several locations are examined by the application successively.

The opening sequence for launching a merged application is:

4D tries to open the Last data file opened, as described below (not applicable during initial launch).
If not found, 4D tries to open the data file in a default data folder next to the .4DC file in read-only mode (new in 4D v15, described below).
If not found, 4D tries to open the standard default data file (same name and same location as the .4DC file).
If not found, 4D displays a standard "Open data file" dialog box.

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?

My application is not merged, maybe that is the root of the problem. Our current application is in v17 so we have the 2 possible locations, however we will be moving to v18 in the next few weeks. We do have the “Use new architecture for application deployments” checked. I’m actually testing with a newly created database, I think it defaults to checked.

The first line of the documentation is:

“When a user launches a merged application or an update (single-user or client-server applications), 4D tries to select a valid data file. Several locations are examined by the application successively.”

To me this implies it works for a single-user or client server application or merged application.

My real world situation is:

We develop an application on a development computer and have various versions in different folders (one for current development, and one that is the latest production release that can be modified for quick fixes).

We use Urban Code Deploy to do the install from development into production. Urban code is an application that can stop the 4D server running as a service copy in the new .4DC along with other files and start the service. Urban Code can be scheduled to be run hands off.

The problem that we are running into is that the .4DC has a path to the data file location in dev which does not mirror production. So the service terminates when 4D Server can’t locate the data.

My thought was that I could use the Default Data folder or have a blank datafile located in the same folder with the same name so that when 4D looks for the datafile in the last link location and doesn’t find one, it will default to the empty one instead of asking the user. When an empty data file is opened then we would set the correct location automatically via code. This would allow us to remain hands free and not need to open the 4DC in dev with a path setup similar to production to set the last data file location link.

The idea is to be able to select the correct datafile on deploy with out human intervention.

We are currently running 4D v17R6 in production.

There are a couple of things we plan on doing in the future that might help.

1 - We will move to v18R2 in the next couple of weeks. Since the last datafile is stored externally we might be able to use that to keep the location path of the data file constant in production.

2 - We are planning on moving to a merged application server to make deployments easier. Then perhaps we could use the Default Data folder concept and it would work if they are merged.

The page is titled “Data file management in final applications” and “final” in 4D parlance is synonymous to “merged”, “engined” or “built” applications.

I understand that the use of an “or” implies that what follows is an alternative possibility (i.e. not a merged application), so I really can’t defend that grammar, but I think the intent here is to include a “launch” as well as an “update”.

A “fresh” .4DC file does not have any data file preferences (DataFilePath only works for “final” applications). I assume that the data file path from development is stored in the 4DC because a. it is not a merged application and b. you opened it before moving to production. “lastDataPath.xml” is reserved for merged applications.

If you already know the data file for the service in production, perhaps you could do one of the following:

  1. Use Command Line Interface to specify the data file during service startup

  2. Either in development or production, open the datafile indirectly, via a 4DLink file placed next to the .4DC. The path of the link file (./whatever.4DLink) is stored in the .4DC, not the real data file path.

I like your option 1 idea, use the Command Line Interface to specify the data file during service startup. I found I can edit the path with Regedit and add the datafile to it.

This approach will work until we start using built servers.

Thank you for the suggestions.