Many FileMaker developers use FMP URL links in order to get FileMaker scripts to run from actions taken in a web viewer. For example, this is how DayBack calendar runs your FileMaker scripts when you edit an event in the calendar.
When FMP URL links are functioning properly, these scripts can update records flawlessly. When they don’t work correctly, they may try to open another copy of FileMaker, or just fail silently. And things that fail silently can be really hard to hunt down.
When we were trying to come up with a way to verify that a client’s FMP URL links were working properly, we first came up with the idea to run a script upon opening the file that uses the “Open URL” function. This URL sets a global variable in the file to “true”, which is then checked further in the script to verify that FMP URL links are functioning. If the variable is not set, then the script throws an error.
Here’s our first attempt at seeing if the URL was firing:
Unfortunately, we found that the “Open URL” script step sometimes resulted in the test passing, even when FMP URLs were not functioning properly.
It turns out the “Open URL” script step works just a bit differently than FMP URLs started in the web viewer: the script step almost always targeted the correct version of FileMaker, while the same URL called from the web viewer would not.
It seems the only way to definitively test the functionality of FMP URL links is to start the test from a web viewer or a browser: we opted make a web page available that the user can browse to and click a link to run a script in the file.
You can see our test in DayBack’s documentation here: FMP URLs
One caveat to this method is that the user’s file name must match the filename in the link. This is why we’ve included instructions on copying and pasting the link into their browser’s address bar, customizing the link to their own file name.
FMP URL link issues can be tricky to diagnose. Hopefully, this can be helpful for those of you running into the same issues in your environment.