Bug: external script call

[ignotum]

(This has been reported to FMI with no response thus far.)

 

Filemaker 16 FMPA & Server Mac client, PC server

Scenario: I have a client's "MASTER" file HOSTED on an FMS at a hosting company. I have a copy of that "MASTER" file on a development FMS at my office.

After that copy was made I added a script to both MASTER files. (wrote it on one, copy/paste to the other)

I have a LOCAL file that calls that script in the MASTER file.

In my LOCAL file I set up the External File Reference to the MASTER file on the hosted FMS.

I set up the script in the LOCAL file to call the MASTER file script on the hosted FMS.

All is well.

I then change the External File Reference to the MASTER file on my development server.

Now when I look at the script in the LOCAL file I would expect one of two things: the Perform Script step to the script on the MASTER file would either:
1. still be connected to the correct script or (more likely)
2. show <unknown> for the name of the script it is looking to call.

BUT INSTEAD the call is linking to an entirely different script. It has a different script in the Perform script call - one that has nothing to do with the process.

Clearly this is a dangerous bug.

I can (probably) solve the issue for me in this one case by grabbing a copy of the client's MASTER file to my DEV server then relinking the external script call. At that point the call should "stick". BUT this is a potential data-damaging bug that could crop up in any similar client/development environment.

Mark

[Fitch]

It's not exactly a bug. When you call an external script, it points to the internal ID, not the script name. What's happened is that your script IDs in the two copies of the 'MASTER' file are out of sync.

This function will give you a list of script IDs:

ScriptIDs ( "")

And this will give you the names:

ScriptNames ( "" )

I can't tell from your profile if you have FileMaker Advanced. If so, you can just use the Data Viewer to run the functions. If not, you can set a field or something. Compare the results from both copies of the file and you'll see what's going on.

[ignotum]

The bug is that the external call is picking a script rather than returning "unknown" and failing. But running a different script data damage is possible.

Hard to believe that internally FMI has chosen to use a simple serial number for ScriptIDs rather than a UUID/hash of some sort... not what most would call a "best practice".

[Fitch]

I understand. And I'm saying it's not really a bug because FileMaker is connecting to a script with the same ID as the script in the other file. So it's not 'unknown.' If scripts were deleted such that it couldn't connect to a script with the associated ID, then it would return 'unknown' and you'd remain blissfully unaware that your script IDs are out of sync.

I agree it would be great if FileMaker provided us the tools to synchronize script IDs in multiple files on multiple servers. You could suggest that as a product idea (good luck with the details). Until then, it's incumbent on us as developers to manage our own deployments.

[LaRetta]

10 minutes ago, ignotum said:

Hard to believe that internally FMI has chosen to use a simple serial number for ScriptIDs rather than a UUID/hash of some sort... not what most would call a "best practice".

I agree ... it is far too easy to match to an incorrect script using simple serials (same for fields, by the way).   If FMI switched to true unique IDs, it seems much safer.

[Fitch]

In case anyone is still not clear, let's say Master A has these script IDs/script names:

1 hello
2 goodbye

Master B is a copy, so the same initially. Then I add a couple of scripts:

3 calculate pi
4 eat cake

Then I delete script 2, so my script list in B is now :

1 hello
3 calculate pi
4 eat cake

Now I copy 'eat cake' to Master A. The next sequential script ID is created automatically, so... it now looks like:

1 hello
2 goodbye
3 eat cake

Still with me? So then I point my local file to Perform Script 'eat cake' in A, in other words, I'm pointing to script ID 3.

Now I change my file reference to B. Now Perform Script still points to script ID 3, but it's a different script in B.

[LaRetta]

You explained it very well, Tom!

And if FMI used true unique IDs, it wouldn't fire an incorrect script.  It would break which we would prefer.

[ignotum]

Or if FMI let us see the script name AND the ID when specifying we could reasonably take responsibility for the issue - and also: we should be able to change the ID (validating unique) if we need to match across >1 file.

Edited October 4, 2017 by ignotum

[Fitch]

3 minutes ago, LaRetta said:

And if FMI used true unique IDs, it wouldn't fire an incorrect script.  It would break which we would prefer.

Switching to UUIDs would mean getting 'unknown' instead of potentially the wrong script, so we might spot the error sooner. But depending on what the script does, you'd still potentially lose data. I.e., it doesn't absolve us from exercising due care when developing.

Take note, anyone working with the separation model: be careful when adding scripts (and fields) to your data files!