DeplDeployment Time: 12:00 PM PST
Features & enhancements
None
Bug fixes
| Item |
Description |
| Bug |
Fixed a bug where “discard changes” would make the local cache invalid, forcing a full sync on the next app start rather than starting with local data. |
Rollout changes
| Item |
Description |
| Feature |
Track changes made to a row in an AppSheet database
The Update Row Timestamp column data type specifies the last time data in a row of an AppSheet database was changed through the AppSheet database editor or the app. The value is displayed using the local timezone and is read-only. For more information, see Track changes made to a row in an AppSheet database.
New: Deployed to all users.
Previous: Deployed to 100% of free users and 50% of paid users.
|
Preview announcements
Preview feature releases enable you to try out new app features that are not yet fully supported. See Product launch stages.
- No new preview features were released today.
The following tables summarize the preview features that are currently available.
| Item |
Description |
| Feature |
AppSheet apps for desktop users (Preview)
The new desktop design, currently in preview, is optimized for desktop browsers, presenting a more complete view of information with a consistent organization and structure. The new desktop design lets users navigate their apps more easily and access information in context, and provides an efficient way to edit existing records without losing context. The legacy desktop design, enabled by default, provides an experience similar to the mobile and tablet device.
For more information, see:
- Community article
- Optimize the user experience using the new desktop design (Preview)
|
In addition, the AppSheet preview program lets app creators try out new app features that are not yet fully supported. For more details and to opt-in, see AppSheet preview program.
3 Likes
“Fixed a bug where “discard changes” would make the local cache invalid, forcing a full sync on the next app start rather than starting with local data.”
@lizlynch if I am reading this correctly, this is fantastic news. I had a user yesterday that had to forfeit about 100 changes waiting in the queue because of some minor error. Will this not be the case anymore?
1 Like
@Ryan_Wagner Just curious if you had tried recovery mode and also didn’t work.
2 Likes
@Ryan_Wagner The fix is about app start-up, and whether a fetch of the app configuration from the server is required to start the app. Sorry to say this will probably not have much effect on issues involving writing data changes back to the server, but it may depend on the nature of the error. The bug could potentially cause the app to pick up a later version of the app than had been running previously (if a new version was created or stable version was changed since the last sync), so if there were older changes queued at the time then the version mismatch between the running app and the queued changes might contribute to sync errors if the schema had changed significantly. This fix would help avoid that situation. But if the schema did change significantly since the changes were queued, they may fail to sync anyway even after this fix. Recovery mode is usually the best option in these situations.
4 Likes
@Joseph_Seddik @Adam-google Thank you both for the replies. I was under the impression that “show changes” and “reset changes” were the only options, unless that is what you are both referring to as “recovery mode.” Typically, I ask the users to email me via “show changes” all the edits that were stuck unable to sync, but the resulting list is a real nightmare to try and doing anything about.
I used to do the same thing, but more recently the list of changes under “Show Changes” just has one single change, repeated XX amount of times. I don’t know if it was intentional, but when users would hit “Show Changes”, a pop up would appear saying something along the lines of “Changes sent to AppSheet” and then they would appear as individual .txt documents in the “_recoveryData” folder. That made it significantly easier to sort through and capture any needed data.
1 Like
Recovery mode is mentioned here in the documentation on sync errors. It functions similarly to having the user send the changes, but it doesn’t require the user to do anything more than attempt to sync. With recovery mode enabled, the changes that would normally fail to sync are instead written to a separate folder in your storage provider, so the user’s sync can be unblocked. Getting the changes from there into your source data still must be done manually though, since the nature of the error is that the system is unable to automatically map the old schema onto the new one.
2 Likes
Hi @Adam-google I’m pretty sure that I had occasions, where the recovery mode did save the changes in the google sheet. Or is this really not happening?
1 Like