Appsheet syncing problem

is there appsheet syncing problem, all my apps cannot sync and can not sync data to cloud sql MySQL database, any suggestions, please

There are several other posts in the community about this.

Thanks @Steve,

Hello @khalee,

I apologize for the inconvenience caused, the engineering team is already working on this.

As Steve correctly states, there are other posts for this issue. This is the one I am using to provide with updates:

Hi @Jose_Arteaga, related but different issue — not data sync, but view/menu NAMES not updating even in the editor Preview.’

Bug report — View names not updating in the mobile menu (AppSheet)
App ID: (PII Removed by Staff)
Report date: August 7, 2026
Affected area: Editor / Views (UX → Views) → Mobile navigation menu
Channel: Free account — posted on AppSheet Community, no access to 1:1 support
Summary
After changing a view’s “View name” field (from “Conciliación Pagos” to “Conciliación”), the new name is never reflected in the navigation menu (Primary/Menu Navigation) — not even in the editor’s own Preview, which runs directly against the app’s latest definition, without going through any external client or device cache.
Expected behavior
After editing “View name” and saving, the app’s side/bottom menu (and the editor’s Preview) should show the updated name within seconds.
Actual behavior
The menu keeps showing the old name (“Conciliación Pagos”) in:
The native mobile app (iOS/Android)
The editor’s web Preview
A brand-new incognito window, no prior cache, signed in with the same account
Steps to reproduce
Open the app editor.
Go to UX → Views → open the view with Position = “Menu Navigation”.
Change “View name” from “Conciliación Pagos” to “Conciliación”.
Save (save icon confirms no pending changes).
Check the menu in Preview, in incognito, and on the phone: the old name persists in all three.
Diagnostics already performed (so support doesn’t need to repeat them)
Pull to refresh on the phone → does not fix it.
Manual sync (sync icon, not the refresh gesture) → does not fix it.
Fully closing and reopening the app → does not fix it.
Creating a brand-new view (name and internal ID never used before) pointing to the same data → inherits the old name too. This rules out any caching cause, since a new view was never previously synced.
Editor Preview → shows the old name (rules out a propagation issue toward clients; the problem is in how the definition is saved/generated).
Brand-new incognito window, signed in, never used with this account before → shows the old name.
Forcing a “dirty state”: changing Position from “Menu Navigation” to “Not in Menu”, saving, then back to “Menu Navigation” → does not fix it, Preview still shows the old name.
Checked for pending errors/warnings in Audit → No errors.
Opened the editor in a completely different/never-used browser → Same issue persists (rules out local editor cache).
Checked for overrides in Data → Localize → No translations/overrides saved for that text.
Technical conclusion
Since the editor’s Preview (which reads the latest definition directly) also shows the old name, a new view inherits it too, the same behavior repeats in a completely different browser (never used with this account), there are no pending structural errors in Audit, and there are no translation overrides in Localize — this cannot be explained by client-side caching, editor caching, or propagation delay. Every configuration-side cause available from the account has been ruled out. Everything points to the “View name” field not being correctly persisted in the layer that generates the menu on the backend, even though the edit screen shows it saved as “Conciliación”.
What we’re asking support/the community for
Investigate why this specific view’s “View name” field isn’t reflected in menu generation, despite attempts to force regeneration (toggling Position).
Confirm whether there’s a cached value on the server/backend side tied to this App ID that’s overriding the current name.
If this can’t be resolved from the account side, confirm whether this is a known bug and its resolution status.
Note: every troubleshooting avenue available from the user’s account has been exhausted (see checklist above, all items ruled out). Requesting direct backend/engineering-level review, not additional client-side troubleshooting steps.