deployment issue

[helenyeliu]

Hi,

  When I try to deploy my application, I got this error. Does it mean that google sheet cannot include formula for deployment?

Thanks,

Helen

[dbaum]

It looks like a warning that's notifying you of a property mismatch that AppSheet automatically corrected. Maybe try deploying again? You could also try regenerating the column structure for the table to ensure there are no lurking mismatches between the data source and the app.

[helenyeliu]

Thank you! deploying again has the same problem. regenerating the column structure for table CLEANESGLeaders, right?

Thanks,

Helen

[dbaum · Accepted solution]

Presumably, yes. Whichever table includes the column from the sheet cited in the error message.

Also, as @SkrOYC noted, it may be possible to accomplish fully within AppSheet whatever your spreadsheet formula is doing.

[helenyeliu]

It works now. thanks!

[SkrOYC]

---

@helenyeliu wrote:

Does it mean that google sheet cannot include formula for deployment?

Even if it doesn't, I wouldn't advice anyone to use spreadsheet formulas. Use your worksheet as a database, forget about the common GSheets/MSExcel usage you could be used to

[helenyeliu]

Thank you!

[Swoopy]

In some situation using spreadsheet formulas helps reducing sync-time & laggy on AppSheet ("A LOT") IF ("IF") the formulas reduce calculation loads on AppSheet.

I've done removing SELECT(...) expressions used on many apps by alternatively using spreadsheet formulas and the results are very satisfying.

[SkrOYC]

Sure, I'm just saying that probably we need to think about our expressions a little bit better before something like that.

Taking Select() expressions for example, the main usage is by doing the Select(Table[Column],...,...) but you could instead reduce the amount of rows by Select([Related ABCs][Column],...,...) if your schema allows it.

Things like that are the ones that I think we should care the most and probably you get to understand those after a year of playing with AppSheet.

Also, the main problems related to performance are on the sync side, which is also related to the usage of unefficient virtual columns. This ones can't be replaced with spreadsheet/worksheet formulas, only real columns, and by that point real columns are calculated once you edit a row and not at sync, so I don't know where the value is.

IMHO, spreadsheet formulas are there for two reasons/cases:

• You don't know how to do something inside AppSheet
• There is a GSheet/MSExcel function that AppSheet doesn't support via it's own functions

Btw:

• Spreadsheet formulas work as App Formulas and not as Initial Value
• Changes are on the spreadsheet so you don't get real time local calculations, that you get using virtual columns for example or by editing a row with a real column having an AppFormula

[Swoopy]

---

• You don't know how to do something inside AppSheet
• There is a GSheet/MSExcel function that AppSheet doesn't support via it's own functions

---

>> I'm using them interchangeably. Specifically for AppSheet's SELECT() which is worst performance nightmare creators should avoid when possible (unless you're dealing with just few hundred rows apps). You can have GSheet doing SELECT's job processing on its server which is (I believe) much faster than doing in VC (proven by clearly improvement seen on my apps either at sync time or moving between views). Then on the app side just use LOOKUP() to peek at the results processed on GSheet and use them across VCs as usual.

Beside I believe the VC's calculations are mostly (if not all) done on device. As seen different devices give different performances upon their processing power. It's not like using device as terminal of AppSeet's server. They are processing right on your devices, of course. That's why sharing processing loads to GSheet gives me better performance.

[Swoopy]

---

• Spreadsheet formulas work as App Formulas and not as Initial Value
• Changes are on the spreadsheet so you don't get real time local calculations, that you get using virtual columns for example or by editing a row with a real column having an AppFormula

---

>> That's correct. I'm not encouraging creators to replace every SELECT on app side with my mentioned practice especially when the fast calculation matters to app's user. Though on a view handling 40,000+ rows, the delay before the change appears on screen is about 15-25 seconds.

[Swoopy]

you could instead reduce the amount of rows by Select([Related ABCs][Column],...,...) if your schema allows it.

---

Even this shorten version of SELECT still gives worse performance comparing to my mentioned practice. Note that I'm talking about apps with related tables holding 30,000+ rows.