That's exactly what I do and it works for me.
Are you sure you have the "run with full access privileges" option selected for this script?
If you are, I'd try recovering the file and testing the recovered copy to see if that fixes the problem.
That's how I thought it would behave. I'll see about recreating the portal, writing a new script, a new layout and eventually recovering if nothing else fixes it. Do you know if "run with full access privileges" would change if the related records are in a separate file as I have it rather than 2 tables in the same file? The users and permissions are consistent across both tables.
…writing a new script,…
Are you using a named script instead of a script step to delete the portal row? If so, then you may want to edit the Scripts access of the privilege set to ensure that the users can execute it.
"Do you know if "run with full access privileges" would change if the related records are in a separate file as I have it rather than 2 tables in the same file?"I don't know. That is different from what I've done. You could make your delete script use a GTRR on the other file's table and then perform a "run with full access" script in the other file that deletes the record, if you wanted to test that idea.
It sort of makes sense. That "run with full access privileges" option may well apply only to the current file.
Thanks. Yes, using an actual script rather than a script step (can't get full privileges on the script step only in the dialog to set it up). All users have access to run all scripts.
I was doing exactly that as you were responding.
Script still run from button in portal row. Script asks for verification of delete while looking at portal row in master record, go to related record, call script in related record file to delete selected record without dialog, commit records back in master record file.
It works, but it is not very clean to me. The user sees it as though the single step works though.
Thanks for helping me along.
Yet another reason to subject one's self to the pain and aggravation of merging old single table files into unified multi-table files.
I agree. Our system used to be 40 files. I'm down to 15. Still working on the consolidation in the background of my real work here. This issue came up as part of the file reduction I've been working up to since FMP9 came out.
We had over 50 files and I had to play games behind the scenes to keep the boss from hitting the 50 file limit when he tried to open everything on one machine. :smileysurprised: I've got mine down to 10 files and hope to eliminate one of those in the near future.