Column not sync quikly

Hello, I have an app that captures the information of a purchase order. I have the “purchase header” table that has the customer data and the order total, and another “purchase detail” table where I keep the products related to the parent “purchase header” table.
In the “purchase header” table I have a column called “total purchase”, but every time I add a new product to the “purchase detail” table I have to wait a few seconds while the “total purchase” column is updated. Do you know of any way for the “total purchase” column of the parent table “purchase header” to be updated more quikly?

see the example:


Could you please update what kind of column "total prchases " in the parent table is. Is it real column or a VC and is it with spreadsheet formula or app formula?

1 Like

Hi @Suvrutt_Gurjar it’s a VC, try a real column whit app formula but unfortunately it doesn’t work eitherHi @Suvrutt_Gurjar ,

Thank you. Is it possible that you could share the expression for the column.

1 Like

Captura de Pantalla 2020-05-14 a la(s) 1.25.04 a. m.

1 Like

Thank you. May we know if you have a very large number of records in the child table?

In that case I believe the performance of the Rev_Ref VC column [Related Detalle_Pedidos] may need to be checked.

As per my understanding Reverse_Ref columns are also SELECT() columns with underlying expression as SELECT( Child Table[Child Table Key], [Ref. column in Child Table]= [_THISROW].[Key Column of Parent Table]
So being SELECT() expressions, I believe they need to scan entire table to get the desired resultant row references.

So if there are many records ( Many hundreds or thousands) in the child table, this could be impacting the performance of Rev_Ref column.
Edit: Corrected a few incorrect spellings


@Suvrutt_Gurjar, while I agree a large data set could impair performance, I suspect that isn’t the case here.

Praveen has said that the Related … columns added by AppSheet automatically are reasonably fast, even for large data sets. Were their performance a problem, it would also be evident in how long a normal full sync takes, but the poster doesn’t mention that.

My suspicion is that the delay is because the Related … columns (Related Detaile_Pedidos in this case) are virtual columns, and only updated as part of a sync. After a row is added to the Detaile_Pedidos table, there is a few second delay before the background sync pushes the update to the AppSheet server. It is at that time the server recomputes the virtual column and sends its updated value back to the app. When that updated virtual column value gets to the app, the app can recompute the new sum.

The only option as I see it is to force the Related … virtual column update from the app itself by updating a normal column of its row. An update to any normal column of a row will also prompt an update of its virtual columns. To accomplish this, you’ll need to identify a normal column of the Purchase Header table that can be changed in some trivial way, create an action that makes that change, and attach the action to the form and/or action set that adds the row to the Purchase Detail table.

Or you can just wait a few seconds for the update as you do now. :slight_smile:


correct, what i do now is force sync. try an action (data: set the row …) called “refresh the field” that when executed selects and sum all the subtotals of the child records, but it doesn’t work either. try filtering the child records using a slice and it doesn’t work. Also, in a physical column that has an app, the formula is updated through an action that modifies a counter in that row, but unfortunately it does not work. and in many other ways, the truth is that I must expect that there are no pending red numbers to synchronize and a few seconds later, any of the ways I comment works, but after hoping that there are no pending changes to save.

1 Like

I am using very few records :frowning:

Thank you @Steve. Your explanation is very useful. I agree with your analysis.

1 Like


Ok, Thank you for the update.

Related to Formula to calculate mutation no longer working.

There was a regression in a recent performance optimization that’s caused some formulas of the form [List of Refs Column][Other Column] to fail to recognize newly added rows. We have a fix for this pending, I expect it should take effect within a day or so.


@Adam Thanks a lot… It works very well