I just ran into a use case that left me with missing data and Iโd like to confirm if what happened really is the expected behaviour or if something is amiss.
Context and sequence of events:
What happened then is that when those 88 updates synced, they not only wrote the expected value in the one boolean column related to the workflow, but they also reverted all other columns to the values that were present in the sheet in the morning, erasing all traces of the deliveries that had happened throughout the day.
When the end-user of an app updates the value of a column, does the update write just that one column, or the whole row as it was before the update + the updated value in that column?
Solved! Go to Solution.
Hi @Filipe, Iโm sorry about the data loss. I can explain what happened and give a suggestion about how to refactor your app to prevent that.
As you suspected, changes to your data happen per row, not per cell. So the change that is sent from your device is the entire row of data from when the action runs. That means that other changes to the row are going to be overwritten, in accordance with the โlast writer winsโ policy https://help.appsheet.com/users/concurrent-usage-with-multiple-users
One workaround you might consider is splitting your table into two separate but related tables. So for example, you might have a master table of packages, then a related table of delivery info. Your action could set a flag on the master table, and then when the package is delivered, a related row could be created on the deliver info table. I know that this isnโt ideal, but itโs a consequence of how AppSheet does updates.
Iโll forward this thread along to my colleagues to see if they have any ideas or suggestions.
Hi @Filipe, Iโm sorry about the data loss. I can explain what happened and give a suggestion about how to refactor your app to prevent that.
As you suspected, changes to your data happen per row, not per cell. So the change that is sent from your device is the entire row of data from when the action runs. That means that other changes to the row are going to be overwritten, in accordance with the โlast writer winsโ policy https://help.appsheet.com/users/concurrent-usage-with-multiple-users
One workaround you might consider is splitting your table into two separate but related tables. So for example, you might have a master table of packages, then a related table of delivery info. Your action could set a flag on the master table, and then when the package is delivered, a related row could be created on the deliver info table. I know that this isnโt ideal, but itโs a consequence of how AppSheet does updates.
Iโll forward this thread along to my colleagues to see if they have any ideas or suggestions.
No worries @tony, I could rollback the sheet to a point before the data loss without much hassle. I just always assumed Appsheet updated individual cells and was hoping it was something on my end I could fix.
Thanks for the suggestion, I may give it a try.
Would Appsheet always update whole rows even using a MySQL database, or is it strictly a constraint of the Google Sheets API?
Cheers
@Filipe The row-level updates happen independent of the data provider. So the same thing would happen with a MySQL database.
Ok, all clear @tony, thanks.
User | Count |
---|---|
40 | |
34 | |
29 | |
23 | |
17 |