AnsweredAssumed Answered

External data source using variable. Big issue.

Question asked by carlo.motzo on Jan 22, 2018
Latest reply on Feb 19, 2019 by mukai

Hi. I found a big issue using variable in external data source.


I created from the scratch a new solution.

Fm16 and fms16 (Or fm16 in local).

mac and win, all Os

Data separation.

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.



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, on opening, you get the request to locate the data file.

No apparent reason. No crash.

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.



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, without asking where is the data file.



If in production, all the users are in panic until you disconnect them and substitute the UI file.



At a point, FM probably sets something, somewhere, (cache?), 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".


PLEASE FILEMAKER investigate ASAP on this!

We can't reliably deploy our solution!!!