Undo a deleted record

[Ziphius]

Does Filemaker Pro not have a way to "undo" the accidental deletion of a record? For example, when trying to delete a child record within a portal but the entire parent record gets deleted, is there no way to get that data back?

[bruceR]

Nope. That's just one reason why server and routine scheduled backups are important.

[Ziphius]

Wow, I wonder why Filemaker does not adopt an undo feature, seems like a basic necessity. Yes backing up is important but not always easy to do after every single database modification. It would be so much easier to simply hit the undo button when a mistake is made (since we all eventually make a mistake). I'm sure this feature has been requested a million times before but for some, most likely logical reason, they don't want to include this feature.

[Vaughan]

FMP does not have to include all possible features: it's a development environment, there is nothing stopping a developer from creating an undo feature for deleted records themselves.

Use custom functions to control the delete command; import the record into a "deleted" table; delete the record.

FMP is a development environment. If it doesn't have something you need, build it yourself.

[David Jondreau]

I can sympathize. Filemaker does include a lot of features expected of "modern" applications, but Undo is not one of them.

[bruceR]

Probably because they're serious about data integrity. Roll your own if you want.

[Ziphius]

I understand that you could code just about anything you want if you are filemaker savvy but then why even have buttons for "find" and "sort", why not just have the user code these in as well. Most likely to make filemaker as user friendly as possible to the novice, who is also most likely to accidentally delete a record and all its related records. An undo function could be a lifesaver. It would essentially be as though I were saving a copy of the database every second and after the unwanted deletion, I simply go back to the database that was saved one second ago, with its original integrity. I'm not a programmer so I don't know how that would compromise the database. Anyway, I guess I will start building my own undo function and hope to see it in future versions. Thanks for the feedback.

[comment]

It is somewhat more complex that one might imagine at first glance. Unlike most applications, Filemaker writes (almost) directly to disk. That's what enables it to handle huge amounts of data that would suck up your RAM otherwise.

Moreover, there's the question of what is the status of a "deleted unless undone" record relative to other users of the solution. Are they allowed to edit it, or delete it? And if they delete it, can this user still undo it? I don't think you'll find good answers to these questions.

BTW, no one can "accidentally delete a record" - they must confirm the warning dialog (that says "permanently"). And certainly no one can "accidentally delete a record and all its related records" unless they set it up that way first.

[Ziphius]

I figured it was more complicated than it seemed. Thanks for clarifying, or perhaps I should say making it clear that it is complicated.

I thought I could delete a portal row by selecting a record in the portal and deleting that record only. I quickly learned that this deletes the parent record and ALL portal rows for that record. Hopefully one only makes that mistake once.

[comment]

I quickly learned that this deletes the parent record and ALL portal rows for that record.

I think that would happen only if you checked "Delete related records…" on both sides of the relationship.

[Vaughan]

I thought I could delete a portal row by selecting a record in the portal and deleting that record only. I quickly learned that this deletes the parent record and ALL portal rows for that record.

That's because you used the wrong command: use Delete Portal Row, not Delete Record/Request.

[Ziphius]

Thank you, did not know that existed, found it as a script.

[Vaughan]

So to summarise: rather than having to create an undo feature for deleted records (or lament the lack of one being built-in to FMP) the solution was to use the correct step for deleting portal records.

I'm passionate about the 5 whys, too. :

http://www.startuplessonslearned.com/2008/11/five-whys.html

[Ziphius]

I think that if everyone always performed the correct steps, then you are correct, undoing an action is obsolete. However, my guess is that we all, experts included, make a mistake once in a while, and the ability to "undo" the previous action would be very beneficial. Unfortunately I don't know filemaker well enough to build my own undo script. Perhaps someone could attach a script here. I will remain optimistic that FM experts will find a way to incorporate it into the software without compromising the integrity of the database.

[bcooney]

Deakos,

Part of what distinguishes a system developed by an experienced developer versus one developed by a novice is that all features are written with attention to preserving the integrity of the data and offering the user either the ability to "undo" or plenty of warning that they are about to change the data in such a way that they'd best be sure they mean it.

This reminds me of the request for a "Back" button. Back to where?...and that's not an easy thing in FM. If I want to go back, and the record has since been deleted, where do I go? What if you were viewing a found set in a list, and since you left the found set changed? What do I show you now?

I suppose that's the crux of it. In a multi-user database system, the state of the data is changing constantly, and so "undo" and "back" are nearly impossible. Too many variables. FileMaker thinks forward!

hth,

Barbara

Edited July 1, 2010 by Guest

[Vaughan]

Barbara, I think you may be on to something... LOL

Deakos, the developer is in control of the solution. There are lots of ways to control delete, including custom menus, access privileges, and regular backups.

[RodSierra]

Yes, well said, I can't tell you how many times I've explained the same thing, but not so succinctly. We allow very little deleting without many checks and usually at only certain privilege levels. Most of the time records are flagged for deletion or cancellation and then filtered to the user to seem deleted, but instead are part of the total history of the table.

[Fenton]

I thought I could delete a portal row by selecting a record in the portal and deleting that record only. I quickly learned that this deletes the parent record and ALL portal rows for that record.

One problem here is that FileMaker needs to allow you to Delete a portal row, by default. So it has on the "[x] Allow deletion" option in the Portal dialog. Then, if you have your cursor in a portal field, FileMaker's Delete Record... brings up the dialog "Delete this one related record". However, if you have accidentally clicked outside the portal, then it brings up the usual Delete record in the dialog, and would then delete the parent record.

Once you put a button in the portal row, with the script step (or script) of Delete portal row (with no script steps causing FileMaker to lose the portal row context beforehand), then you no longer need the portal to have the "[x] Allow deletion" option; it has nothing to do with whether you can delete the row at that point (it just sounds like it does). So, just use a button, uncheck that option, and this problem does not arise.