Same server update applied twice 8 days apart, even though columns changed. How to prevent reliably?

AppSheet AppSheet Q&A
, , ,
1

Hello!

As the title states, I had a user make a change in the app 8 days ago which successfully propagated to the server. The user claims as soon as he submitted the form, he changed screens on his phone to do something else. Yesterday I added a column to one of the tables. Today he opened the app on that phone again, and the last change he made was sent to the server and allowed to successfully edit the row, despite the schema change. This meant I had broken data (column mismatch) for all columns past the one I added yesterday.

I had a previous instance where a user made changes without updating their version of the app after I had made schema changes , and that had disallowed the changes due to the column mismatch, so I thought the aforementioned situation was impossible. I found documentation suggesting this is impossible as well at https://intercom.help/appsheet/en/articles/962247-errors-and-warnings-during-sync

Is there anything I can do to prevent this scenario besides asking my users to make sure their changes are synced before closing the app?

Thanks!

2

I don’t think so.

Apart from making an app that forces update every single time (when you open it and after any add/edit/delete) which is not quite good from a UX perspective

1 Like
3

You should not make changes to your app without notifying the customer before hand and make sure they are well informed about:

  1. Clear guidelines to manage this change.
  2. Deadline to sync their data.
  3. A change window during which they should not use the app.
  4. Notification before and after the change window.
  5. and preferably a regular schedule for app updates that are included in a well-communicated roadmap.

You should be treating this issue as process problem from your side, outside the app scope.

3 Likes
4

Hello. Thank you for your response.

I did all of the things you suggested in regards to the changes I made as part of a managed release process. The data update in question was made several days before my schema changes, and the data reflected that. The issue is that after my changes were made, that user opened his phone to awaken what I assume was a suspended app, meaning it did not receive the confirmation from the Appsheet server of update completion, and thus retried the update. All of this is acceptable behavior, but somehow on this retry, instead of the change being denied due to column mismatch, it was somehow accepted and applied to the row, causing a column mismatch for that row. Perhaps it is related to the fact that the operation had already completed on the server?

Luckily my user base is small so I have communicated to them that they need to be careful about this sort of thing, but I would feel much better about the integrity of my data if Appsheet had rejected the retry, or resent the confirmation of server success without re-applying the update and causing a dirty data update.

1 Like
5

Thanks for your reply. I understand and see you are doing it correctly. To me this behavior is strange, I don’t know.

Perhaps others here can bring in better insight.

6

Best to always add new spreadsheet columns to the right of existing columns, so that old data that finds its way in still ends-up in the originally-intended column. Likewise, rather than deleting old columns, leave the spreadsheet column in place, blank it, regenerate the app columns, hide the column, and mark it read-only.

For instance, a table like this:

Name Address

Blank Address, add Street, City, State, and Zip, regenerate:

Name Column_2 Street City State Zip

At a later time, you can reuse Address/Column_2.

2 Likes
7

@Steve Thank you!

1 Like
8

Thank you so much! This is a great practice for data integrity/backward compatibility that I will immediately incorporate into my workflow.

1 Like