I don't play much with server-side schedules, I just set them up and forget about them.
You've seen in some of my recent posts, I inherited a system. That system relies a bit too heavily on server-side schedules for my taste, but I'll live with that for now.
FileMaker usually is using internal IDs for pretty much everything, but it seems server-side schedules in FMS17 rely on a matching name to run the target script: renaming a script broke the schedule.
Combined with the UI changes of the admin console no longer showing the schedule errors, I had to look at the log to get awareness of that (unless there is something else I should look at; email notifications are not turned on and my experience is they notify you for things that work just as well as things that fail, amounting to a lot of noise in an inbox).
So can someone confirm server-side schedules are sensitive to script being renamed? Has it always been the case?
Lets say schedule A runs script A. If I rename script A to X and also rename script B to A, will the schedule run the script B renamed as A?
What if there are 2 scripts with the same name (not something I would do, but the product does not enforce uniqueness, so it could happen)? Does the script that run is the one on a 'first match' base (possibly sorted by creation date)?
Hard to think I never came across this before today. Am I missing something? Thank you for your feedback.
I did not think about it either because I never renamed a script used in a schedule.
This is similar to the 'Delete records in this table when a record is deleted in the other table' exception.
All FM script steps work in the current context (layout and TO), except this one. When this 'delete related' feature is activated, deleting a record in table A will delete all related records in table B, regardless of the context on which the delete script step is executed.
It acts globally, in all contexts and can lead to unwanted deletions. I actually banned it from my solutions and use scripts for cascading deletions.
Cascade delete apply globally because they are about data integrity and not UI. It is like saying you want an auto-enter to trigger only if you are on layout X: use a script trigger.
You can ban cascade deletes if you want. That just mean that if you want it to apply, you need the user to perform the deletion in the context you intended.
Technically, if you have a data separation model, you could have the cascade delete defined only in another file than the data file. The cascade deletes would happen only if the file where they are defined is open at the time of the deletion (regardless of if the deletion happens in another file).
Now I am curious about the "2 scripts with the same name" scenario. I think I'll do some testing and report later.
FM identifies scripts are identified by internal ID - FMS does not
script steps act in a given context (layout, graph) - 'Delete Record' reaches beyond context if delete through relationship is checked in any of the graphs for a given relationship
I'm sorry, but I consider the cascading delete the rule and not the exception. It is not triggered by a script step, but rather by a CRUD event.
In the same fashion, I do not see auto-enters as an exception to setField impacting only the field the step targets.
I guess it is simply a question of perspective. I'm not trying to argue or convince. My main concern remains about renaming the script where it impacts a server schedule.
So I got back to test this and it gets weird when 2 scripts have the same name:
I started with scripts "test A" and "test B"
renamed "test A" to something else and "test B" to "test A": the script originally called "test B" runs.
renamed the script originally called "test A" to its original name: the schedule still runs the second script (the one originally called "test B" that got renamed to "test A").
I don't know how and I cannot explain how the second script keeps being the one triggered by the schedule: the "matching name" part is there, but when there are 2 possible results, it seems FMS remembers the last one it called (it is not falling back on script creation order or script order in the script workspace)
The inconvenience of using an ephemeral index is that it can change if there are more than one sequence of steps possible to the calling script. The name is technically in this situation more stable.
I agree about cascading deletes. Cascading delete is something really hard to find if solution is original work of yours or made by you not following the convention 'do not use cascading deletes'. I've made that mistake in my solutions sometimes. Although in some really small solutions I might use cascading deletes but then it's intentional and relation graph is really simple.