Some columns don't update properly in google sheets

I have a very annoying problem related to updating the data of some columns, and I think it is a serious bug.
I have already searched the forum and others have had the same problem but no solution has been found.
In practice I have:
[data C] (text value)= [data A] (number value) + [data B] (number value)
This simple formula is correctly recognized by appsheet, and in the app view it is calculated (temporarily) correctly, but in the google sheet it is not updated, and after a few seconds in the app view it is refreshed with the old data…
I have to specify that my table has over 340 columns, could it be a limited performance problem of appsheet?

This behavior tells me that most likely the value IS updating but then being overwritten again by a subsequent edit. Do you possibly have multiple edits occurring very close together?

No, the quantity of columns is not a problem. But if you have that many columns, have multiple edits occurring quickly, you might have a scenario where one of the edits is being delayed - maybe due to slow performance - and causing edits to be applied on the server out of the normal order.

AppSheet is a row-based processing system meaning that the state of the entire row is applied on updates. If the edits happen to be applied out of the normal order, the last one wins - which may result in an edit being overwritten with an older value.

1 Like

how can i check the column update sequence?
I found a user who encountered a problem similar to mine and found a temporary “solution” …
But as specified by him it is not a real solution, and above all very impractical

I just discovered that this solution has an undefined variable effect.
in fact the problem starts to appear again after several hours of use.
This bug threatens to destroy my app if I can’t find a solution :exploding_head:

I’d bet this is at the core of your problem.

Are multiple user modifying the same row?


We can also help better if you provide some context about your app, what it does, why the 340 columns and how is the app is used by yourself and other users.

1 Like

To test this, try it when only you are using it such as very late at night. That way there is not chance of another user saving the same row.

1 Like

The app is still under construction, but it is in a very advanced state by now.
However, for now, only me and a few others are using it for testing.
Basically it will have to serve as a digital tool for a role-playing game and contains numerous tables that I have to interact all with the main “character” and “master” tables with numerous updates.

It may help to read and understand this doc:

I have read and understood, but unfortunately I do not think it is useful for this problem.
For the type of app I’m making, Delayed Sync is the best, in fact for most interactions users will make quick changes in detail views. The problem is that only some of the changes that are set seem to actually update on the database.

I have found that this problem only occurs if I make changes from slice filtered views. In fact, if I make a change using an overall view of the whole table (not a slice), the changes are saved correctly. Are there any limitations of the slices that I have not seen?

ok I understand something important …
Basically I have numerous slices of the same table, and I understand that if I modify a data in a slice, if other data is calculated from that data, but not present in that slice, they are not synchronized correctly. In fact, if I insert all the data in the first slice they are synchronized correctly when I make changes.
is this a bug?

If by “data” you mean the fields/columns, you should add all the columns that are related to the expressions you need, and then you can hide them under UX → Column Order

thanks for your help! I’ll probably proceed with your advice!
even if I think it’s just a way around the problem …

AFAIK If you are adding/editing data from a slice, the slice needs all the columns involved into the calculation of the fields, so this is the expected way of doing it instead of a workaround :thinking:

if this is the case then it is misleading that the fields in the other slices immediately calculate correctly but then do not synchronize.
For this reason I assumed that the slices had only a visual function …

1 Like

Sure, I’m with you in that case.
Or maybe I’m wrong on this.
@Steve ?

I am not clear what you mean by “synchronized”.

There is one thing that comes to mind. If a column is implemented with an App Formula but IS NOT included in a Slice for which you are adding or editing data, the App Formula for that column will not run. The column must be included in the Slice for it’s App Formula to fire.


By this, I assume by “synchronize” you mean that values calculated in one Slice are available in another Slice right away. Yes, this should be the case if all things are implemented correctly.

If you are seeing values calculated in one Slice but not appearing in another right away, then please post images and a more detailed description of where you are experiencing those problems. We can help better that way.

Slice are indeed a visual thing but it’s best to think of them as their own little sub-table. They can only operate on the columns and actions they know about