1 of 1 people found this helpful
couple of options:
1. When a record is deleted ship a copy off to a storage table before it is deleted.
2. Disallow deletes and just set an active/inactive flag field in the table.
Option 1 makes it very difficult to roll back any deletes. A transactional approach is optimal.
Option 2 requires adjusting joins and/or portal filters to work.
For either option and to be thorough you have to get friendly with custom menus so that you can overwrite the delete command.
Don't know how to deal with delete functionality co-opting via xDBC connections.
Thanks for the suggestions! All these options seems feasible (I'll have to experiment).
I think perhaps I'll try the idea of having the "delete" button on the User's side simply set a flag that the portal automatically filters out.
This way, from the User's perspective it still appears like a "delete" function, but on the back end a record of the entry is maintained. Plus, an admin can always rollback the delete, by manually changing the flag back.
Good solutions! Thanks again. Much appreciated!
remember that the foreign key (in the portal record) is a match to the primary key in the parent record. I have sometimes did a "remove" by changing the key in a way that keeps the record, but removes the 'Match':
Set field ( FK = FK + .01)
but I might also have a notes field for WHY this was done.