Data Persistence: "Update" as a new record

[REcycler]

Maybe I am overthinking this, or missing something, so I would appreciate any assistance.

My concern has to do with how records are handled on each table during CRUD operation, specifically the “U” part.

• Create: A new record (row) is created with the data. Perfect.

• Update: The record is overwritten.
  I dont want to lose the data if a user makes a mistake, there isn’t an un-do button.
  SO I have created a behavior that pre-populates a form with the data from the record that my user wants to edit.
  However, this breaks my REF connections.

• Delete: The record is deleted from the table, but there are plenty of ways around that.

Any insight on how to persist my data would be super helpful!

Thank you!

[takuya_miyai]

Hi @REcycler

I understood that you want to control the edit permission you give to users, but I did not understand what process you need to do.
I think it would be easier for community members to answer if you tell us the use case you want to achieve.

[Steve · Accepted solution]

True, there is no built-in undo function. You might be able to create your own, though, or at least keep a journal of the changes.

Suppose you have a table, T.

Create a table, Tj, to act as its journal. Tj should have the columns of T that you want to keep a historical record of. The columns of Tj needn’t have the full configurations of those in T, as users will not interact with Tj at all. The columns of Tj should have the same column types as T, though.

Tj should also have an independent key column–it will not use the key column of T as its own key column. Tj will accumulate rows much faster than T, so choose a key scheme to accommodate that.

Configure Tj to Filter out existing rows, so that the rows of Tj are never loaded into the app.

Create a bot for T that responds to at least all adds and all updates. When an add or update occurs in T, the bot should add a new row to Tj and populate that new row of Tj with the values of the newly-added/-updated row of T. This will ensure that Tj contains a record of all changes to T, including the current rows of T.

[REcycler]

Thank you Steve!

Yes! A Journal of changes is perfect!

[stilllifemuseum]

Hello! I share my method to audit my data:
All my tables in which my users have interaction (adds, updates, deletes) usually have four additional columns that refer to the types:

1 changecounter
2 changelocation
3 changetimestamp
4 (user) email

When a row is updated, changecounter tells me how many times it did it (I can even have changecounter columns that point to certain columns), changelocation tells me where the device was at the time of the update, changetimestamp when, and (user) email who did it .
When I have this data I just have to go to Google Sheets, filter and examine the history by cell. This is also possible with deleted rows.

I hope that soon this type of data that is part of the spreadsheet can be entered into the appsheet system.

Cheers!