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: https://share.getcloudapp.com/GGukdRoE
Solved! Go to Solution.
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.
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?
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.
Yes
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
I am using very few records
Ok, Thank you for the update.
@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.
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.
Thank you @Steve. Your explanation is very useful. I agree with your analysis.
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
User | Count |
---|---|
43 | |
28 | |
24 | |
24 | |
13 |