We have a client solution that we have inherited support after their internal developer moved on.
It's a multi-file solution (not separation model) that has not had a dev>production workflow before. We are creating a set of dev files by duplicating the production files. They will live on the same server, so each dev file will be suffixed with "_Dev". We are changing the direct file:FileName references with dynamic references using global variables.
I'm running into a problem with one of the dynamic file references in the main file.
Right away, the file tells me:
The file “$$File.Email” could not be opened. (Not Found)
If I have debugger open, this dialog happens before the startup script appears in the debugger. Even before a window draws. All of the other dynamic $$File.FileName references are working fine.
Things I've done to try and ensure that references aren't trying to happen before the startup script runs:
Made a new Blank table with no fields and no relationships.
Made a "Splash screen" layout that is completely blank, based on the Blank table context.
Assigned the [Standard FileMaker Menus] to that layout (no custom menus).
Took the file offline and set the layout to the new Splash screen layout, closed the file (no closing script that might have changed that), re-hosted the file.
The startup script sets the $$File.FileName globals right away (but the problem is happening before that has a chance to fire).
I've made sure that the Data Viewer is not open when I opened the file.
Looked for values lists that might reference that file (found none).
Also replaced a calculation that referenced the file with a related record in the only script that referenced that calculation. Didn't make a difference.
Any ideas what else might be trying to load a file reference before any layouts or startup scripts load? Or is there some way that I see what is causing that reference to attempt to evaluate?
I set the global variables in the OnFirstWindowOpenTrigger script. This calls a wrapper script, which then invokes the script in which the external scripts are called to distribute the file references' values:
onFirstWindowOpenTrigger()
distributeFileReferencesWrapper()
distributeFileReferences()
setFileReferences() in external file 1
setFileReferences() in external file n
Layout-wise there should be no fields present and the table must be local to the file. The layout should be set as default (on open).
This works reliably – it seems the debugger always peeks one script ahead and the additional wrapper fixed it for me.
Just a note that changes to some of the "sticky preferences", such as last layout before file close do not stick unless something else has caused FMP to save changes.
I bet you already know this, and regardless, would have caught it if it were happening,
but briefly:
Opening the file, switching to a different layout, and then closing the file without making any other changes to data or code does not make the file remember the new "last layout". In my experience, to get a change like this to stick on a locally opened file, I have to make some other small change which prompts FMP to save changes. Typically I choose something small such as editing a script by adding/removing a line of white space or editing a comment. Saving the script change seems to be enough to get FMP to change other settings such as saving the last window size/position/layout just before closing.
One other thought of something to add to the list things to check:
Are there any custom privilege set calculations which could (indirectly or directly) trying to reach out to the external file?
Does the script which populates the file global vars utilize a reference to the external file?
I did see that you are getting the missing ref message prior to seeing the script run in the debugger, but I like and agree with what Nils has said. The implication is that reviewing the content of the var-setting script is worth checking.
I have a new onWindowFirstOpen trigger script that sets the file reference globals, and then calls the previous startup script.
Let me double-check the startup layout change. I think I made some other changes, so that should stick, but I know I've been burned by that in the past.
Yeah, that wasn't it. Downloaded the file again. It opens to the blank splash layout (but that could be because of the file options open layout setting). Made some script tweaks. Closed and re-uploaded the file. Issue persists.
Why not have a separate server for DEV? If for no other reason than, don't put all of your eggs in one basket.
Having to re-code your system to implement this way of working is a red flag for me. And you are having issues with the dynamic references needed to make the "we live side-by-side" thing work. None of that would be needed if you did development on a separate server.
Unfortunately, we don't control everything for this client. We don't manage their server. Yes, I'd rather have separate dev/prod servers, and I did ask if that was an option and was told no. I could push again, but this seems like such a silly thing to make that case a requirement.
And we've done this for other solutions and never run into this issue.
Are there any custom privilege set calculations which could (indirectly or directly) trying to reach out to the external file?
Good thought, but I checked that as well. There are no privilege set calculations. Everything is either yes or no for the few custom privilege sets.
I've also checked the DDR in FMPerception for External Data Sources > Table Occurrences > Direct References… and nothing there indicates something that would be evaluated at startup.
What would you say to a sanity check of temporarily disabling the file options layout setting and then re-opening the file to confirm that the various efforts to properly set the initial layout to the new splash succeeded?
I understand that, by now, something should have made the initial layout properly set, but actually confirming that to be the case seems like it might be helpful to either rule out a theory or to offer a new line of inquiry...
Dynamic file references were certainly required historically in the earlier days of DMT pre OttoFMS and the Developer command line tool where your dev copy might be named different to production.
However, now that OttoFMS allows you to rename file(s) during the DMT process by way of utilising the FMDeveloperTool, I don't think there is a need for them anymore if the goal is to simply rename a file & references on a deployment. If you are using Otto you can do it all as part of a deployment where it can rename filenames and the internal references, saving the pain of using $$vars for file references.
This was one of the first things we abandoned when OttoFMS added this feature.
In Multi-File solutions they're such a pain. Not only do they have to be initialised in every file on start-up for things to work smooth, they also have to be initialised when doing a PSOS if one file references another, or things just don't work, they're just more hassle than they're worth.
I've been going several rounds with Gemini on this, and that was one of the things it had me check. There was a file access from this file, but I deleted it, and that did not solve the problem.
Regarding what you were saying about OttoFMS, it was actually this article from Proof+Geist that let me to believe that I still need dynamic file references:
This line in particular:
Even though Otto supports changing the filename as part of the migration, it cannot update hard-coded file paths. Whatever you define in the file is what FileMaker uses in the cloned/copied files.
I have a support question in to Ottomatic/Proof, so we'll see what they say.
If OttoFMS can update external data source file names, then I'll feel a little annoyed at the amount of time I've sunk into this… but I'll be glad to have a working solution.
