1 of 1 people found this helpful
Why don't you want to use another layout? This is something that can be completely invisible to the user:
If [ Not IsEmpty ( RelatedTable::ForeignKey ) // make sure that there is a related record ]
Go To Related Record [Show only related records; From table: RelatedTable ; Using layout: "RelatedTable " (RelatedTable ) ]
Delete Record [no dialog ]
Go to layout [Original Layout ]
You really can't delete a record by any other means than portal record deletion or changing layouts without jumping through a lot of extra steps--such as "marking" the record for deleting, disconnecting it from your current record by clearing the foreign key field and using a scheduled script to find and delete all "Marked" records for deletion at a later time.
Thanks, PhilModJunk! I wasn't aware that it was possible to change layouts invisibly (so that's what that 'freeze window' thing is for)! I'll try that first thing tomorrow.
I do find it odd that it would be so... roundabout to do, when the 'base of the (data)base' SQL language can do it in one query... I'm quite familiar with SQL, which is probably part of the reason the solution was so counter-instinctive to me.
And it's also strange that it is relatively easy to create a record in a table (setting a field through a 'no results' relation), yet so hard to remove one. Or did I happen across a 'quirk' by chance, and all this is workaround is sort of a 'safeguard'?
Just my two cents from my layman point of view. Thanks so much again!
Filemaker uses the current layout to establish "context" for most of the script steps that make up a script. Each layout is based on a specific Tutorial: What are Table Occurrences? in Manage | Database | Relationships by selecting that table occurrence in Layout Setup...|Show Records From. That determines what tables supplies records to the current found set and many other crucial details as well such as what table get's a new record with New Record/Request and what record loses a record with Delete Record.
You can think of a Table Occurrence as a SELECT * query with Join clauses, but no specified WHERE or Order BY clauses as those aspects are handled with separate Sort Records and Perform Find actions. This allows for user initiated "ad hoc" queries by example that are significantly different than SQL based queries. It makes many simple queries quick and easy, but can make more complex queries more complicated than the SQL equivalent.
I, myself, have posted a feature request that we be given a scripted way to temporarily establish a table occurrence context without actually changing layouts. Something like:
Set Table Occurrence Context [Invoices]
Sets here execute in the context of the Invoices TO