Maybe someone of you remembers my previous post ( How to avoid FM looking for External data sources ) about an issue related to the use of variables in External data sources.
To go clean, I created from the scratch a new solution.
UI file pointing a Data file based on a variable ($Data).
All FM16 and FMS16.
The UI file is composed of 2 tables.
The first (Users) is unrelated to anything and contains user names and the name of the data file that each user must open.
The second (Viewer) has all the relations to the data file.
The solutions works as follows:
- the startup script goes to the layout Users, based only on fields of table Users, reads the name of the Data file assigned to the user,
- sets the variable $data (the external data source variable),
- goes to the Viewer, which is now connected with the Data file of the user.
Fantastic. It works perfectly.
I think that FM16, allowing the use of variables as external data source, made a huge improvement for developers aiming a build a SaaS solution.
Sometimes (after 1 week, 1 month, 1 day), without any reason, the UI file begins trying to access the Data file BEFORE the startup script is invoked.
So, you get the request to locate the data file.
No apparent reason.
The startup layout (Users) is based on a table unrelated with the data file.
And the solution goes, on closing, to the same layout (I know FM remembers the last opened layout).
At this point there is no way to reset the UI file. It keeps requesting the Data file on opening.
Recover (standard or advanced) doesn't work.
THE ONLY SOLUTION
Is to save the UI file as a clone and reimport the users.
At his point everything works as expected.
The solution goes to the Users layout, where the variable $Data is resolved.
IT'S A HUGE ISSUE
If in production, all the users are in panic until you disconnect them and substitute the UI file.
Our fantastic SaaS solution becomes a nightmare.
ORIGIN OF THE ISSUE
At a point, FM probably sets something, somewhere, that forces the UI file to look for the data file on opening, before the startup script is invoked, even if there is no need of it.
Only saving the UI file as a clone resets this "something".
It's an obvious BUG.
PLEASE FILEMAKER investigate ASAP on this!
We can't reliably deploy our solution!!!
PS - My previous post received many answers. Thanks to all.
At that time there was also a problem of corruption of the UI file. So, the issue wasn't so clear.
The current solution was patiently rebuilt from the scratch and the Recover says the everything is ok.
Thanks to all.