Double feature: external record access calc that calls layout // importing a custom menu

The issues with UI/data separation just keep popping up as I go along!

In my integrated file I had privileges set for record access (deletion in particular) that referred to the layout the user was in (layout that is now in the UI file). With separated UI/data, the privileges calling on layout names or layout tables are no longer protecting my records.

For example:

--> I do not want to prevent deletion entirely in that layout, and I do not want to permit it entirely either.

--> I want to permit deletion when child_table::field <>"√"

--> I want to allow deletion of records (including child records that are √) when the parent related record is deleted.

So my "delete" privilege was set to limit calc: NOT(get(layoutname)="layouts of child table" and child_table::field= "√")

I guess the calls to get(layoutname) now refer to the external data file's layouts (which are hidden). If I force the external file to go to a layout by the same name, then it works again... very convoluted and a route I'd rather not employ.

If using layout names is not best practice for record privileges, does anyone know a better way to achieve this type of record access level -- bearing in mind that I don't have fmp advanced so I can't create custom menus? (I would just disable delete and create, and replace all while I'm at it). I am limited to fmp 9 as that is what our office is equipped with.

However - if it comes to that (fmp advanced)-- if I can find someone who has it, could I just create the menu and then return to fmp 9 (not advanced) to pursue the work?

I'd be most grateful for any pointers. Thanks!