Hi
I notice some problems about sync.
App is projected to allow users to confirm their activities, confirmations are saved in table โinterventiโ but observing timestamp it seems some records are synchronized with data source (google sheet) with large delay (1-3 days).
As if appsheet server saved record but sent this with delay.
Timestamp is the key column.
Can you help me to figure out please?
Row:
[
โ1713โ,
โ03/16/2020 16:03:31โ,
โ03/16/2020_YiNehneeโ,
โ03/16/2020โ,
โordinariaโ,
โ[sync to compute]โ,
โ13:00:00โ,
โ14:45:00โ,
โ1.75โ,
โ341-placeโ,
โordinarioโ,
โPulizia sedeโ,
โAlice XXXโ,
โemail.user@gmail.comโ,
โAlice XXXโ,
โConfermaโ,
โโ,
โโ,
โ1.75โ,
โnon validateโ,
โโ,
โ1โ,
โMarzoโ,
โConfermatoโ,
โ0โ,
โNon contabilizzateโ
]
Properties:
{
โTableNameโ: โInterventiโ,
โapiLevelโ: โ2โ,
โappStartTimeโ: โโ,
โappTemplateVersionโ: โ1.000045โ,
โbuildโ: โ1652bc386c40300ff27e-1584384632775-7b47d53ea4โ,
โcheckCacheโ: โtrueโ,
โclientIdโ: โ35f1c08e-0e1f-49c3-b9b4-0d365d749ff0โ,
โdataStampโ: โ2020-03-16T13:34:33.4710317Zโ,
โisPreviewโ: โfalseโ,
โlastSyncTimeโ: โ2020-03-16T13:34:33.4710317Zโ,
โlocalVersionโ: โ1.000045โ,
โlocaleโ: โit-ITโ,
โmechanismโ: โFormโ,
โrequestIdโ: โ13491993โ,
โrequestStartTimeโ: โ2020-03-17T10:24:56.204Zโ,
โtimestampโ: โ2020-03-16T15:03:34.782Zโ,
โtzOffsetโ: โ-60โ,
โviewNameโ: โinterventi_slice_Formโ,
โRowSizeโ: 237,
โAppTemplateNameโ: โ7fc5c713-8720-4b26-8196-c51dd2200909โ,
โOperationโ: โAdd rowโ,
โRecordTypeโ: โStartโ
}
Solved! Go to Solution.
Hi Sergio,
The Appsheet server always updates the underlying Google Sheet as soon as the client submits the update request to the server. There is no alternative to this.
The Appsheet server has no place to queue incoming client request. Instead, client requests are always processed by the server as soon as they are submitted by the client.
The Appsheet server had no place to store data other than the underlying data store. When an update arrives from the client, the server immediately applies the change to the underlying store be that Google Sheets Excel, SQL, etc.
Changes can be queued at the client because the client is designed to support offline application use. If changes were not applied immediately it is because they were queued in the client.
Was this a deployed app or one under test environment?
Regradless, I would send this to support@appsheet.com
Hi @WillowMobileSystems,
It is under test environment at this moment.
Do you think this can affect this behaviour?
Thanks for your advice.
Most definitely the test environment can be impacted by many things. Remember that AppSheet deploys upcoming changes into this โplaygroundโ for developers to use them before they are rolled out to the production environment. Sometimes, there can be a problem with deploying the change that can hold up processing for a bit.
I am not aware of any significant delays recently but that doesnโt mean they werenโt there.
Your delays seem extraneous so I would encourage you to reach out to AppSheet if for no other reason than to make them aware of the problem just in case something more significant has occurred that they need to know about (if they donโt already).
I will do it and I will be back to share more info from support if useful for community.
Thanks
Hi Sergio,
The Appsheet server always updates the underlying Google Sheet as soon as the client submits the update request to the server. There is no alternative to this.
The Appsheet server has no place to queue incoming client request. Instead, client requests are always processed by the server as soon as they are submitted by the client.
The Appsheet server had no place to store data other than the underlying data store. When an update arrives from the client, the server immediately applies the change to the underlying store be that Google Sheets Excel, SQL, etc.
Changes can be queued at the client because the client is designed to support offline application use. If changes were not applied immediately it is because they were queued in the client.
Thanks @Phil. Clear!
User | Count |
---|---|
40 | |
34 | |
28 | |
23 | |
17 |