Restoring Deleted Records
There's this special feeling you get when developing software where you feel like you've created something magical. Sometimes, it doesn't even matter if you've done the same type of thing before. It just feels like you're the master of the universe and you've created something super useful.
This may even be the case when you're simply creating a virtual trash can and providing users with the ability to reverse course on that accidental record deletion.
In this video, we're taking a look at a super simple trash can metaphor. It's easy-to-implement and allows users to bring records back from the dead.
While there are multiple ways to handle record deletions, many of which are discussed in this video, the whole concept of being able to dig in the trash and take something out is familiar territory for many computer users. We're just going to emulate it within our FileMaker systems.
Comments
Error Importing Custom Function
When I try to import the custom function into my project, I get an error that the name "table" is already used and will not import. Not sure why this would be happening...
---- Nash
There's an existing symbol for "table"
In "developer speak" the keyword of "symbol" typically means something that represents something else. In this case, you likely already have a symbol for the keyword "table". That means you either have a field, table (named table) or another custom function.
The solution for this is pretty simple. You can edit the custom function by copying it into an empty database. It will take the function with the parameter name of "table".
You then rename the parameter to something like "tableName" and update the references within the custom function.
This will then allow you to get the function into your own database system.
-- Matt Petrowsky - ISO FileMaker Magazine Editor
AsJSON
We’re fond of using an asjson field in the table. I was wondering if you considered that, rather than building the record json in a script or custom function. If you did consider it, why did you decide against it? Perhaps because it isn’t dynamic?
I've used both methods
I've used calculated fields within the table and it works just fine. However, the fact that a Custom Function is independent of context is a big benefit to many of my solutions where the Custom Function can determine the context and adjust it's output.
I'm also not a big fan of adding what I mentally consider "field clutter" to the schema. If I can keep the tables super trim and still facilitate the desired functionality, then I tend to opt for not using a dedicated field.
Although, there are those circumstances where I will use a field. It always depends on the use case and circumstances I guess.
-- Matt Petrowsky - ISO FileMaker Magazine Editor