Instantly Restore Deleted FileMaker Records
Instantly Restore Deleted FileMaker Records? How is that possible? As it turns out, it’s not that all that hard, but does require some up front planning.
The secret is to put new related table in front of the table with the data, and relate the new table to the old table based on the primary key. The new table has only the one primary key – all other data is pulled into the layout from the table with containing the data through the relationship:
Finally, the most elegant solution: create a new ‘active records’ table and put it in front of the real data table. Store only primary keys in that active records table and link it to the real data table via a one-to-one relationship. Here’s an example with an article table where you want to hide obsolete articles:
Create the Article table the same way as usually, but DON’T activate the serial number auto-enter option for the __id field. Then, create another table, ‘ArticleActive’ and define only one field: the __id field there, with the serial number generation turned ON. This table will contain one record for each active article. Here is what the Relationships Graph should look like:
Here’s how that relationship is set up:
Since the context is always on the table with only the Primary key, if that record is deleted, it appears that all of the data is deleted. Instead, the related data is untouched. It simply does not show up in the main table due to the lack of a matching record!
A challenge for those out there using Todd Geist’s Selector or Session model: How would you integrate this restore technique into those models?
This is a great example of thinking outside the box by Jan Zelenka of ClickWorks. Read the whole thing and download the sample file.
More…Instantly restore deleted FileMaker records | Clickworks.
February 13, 2015 @ 2:12 pm
Sounds like a lot of work and more problems.
Easier would be to use a toggle field for relating to the UUID. When the record is marked as deleted, this field is set to empty. If not deleted, the field is set to the prime UUID field.
Since some relations have difficulty with a calculated field, I suggest using a script performed by the deleted button.
It is also possible to use a text field with a script set by the button on the filed definition dialog. I believe this will update the script when the delete field changes and not face the problems of calculated fields.
The suggested method will work for the one table, this will work for ALL relationships assuming they are pointed at the toggle field.
Of course this may create possible problems.
Both may work better than the method I was forced to use by a client who wanted to remove deleted records from the main file but keep a separate file of deleted records… Then decided that I should move some back to the hot file. He paid well.