App freezing upon action button pressed.

[noahbeach82]

This happens on all my action buttons where records around 100 row or so are being updated or inserted. I am assuming it is because of large datasets. However, the way appsheet should handle this is you press the button and the actions take place in the background instead of my app freezing up until the action is complete. Right now i'm looking at my app and it is frozen on the confirm action screen. It is odd because the data isn't that large. I have it entering about 200 rows into the spreadsheet and it is just frozen. 

[SkrOYC]

It depends on your action.

I have updated 600+ records with a single button but it obviously freeze the app and I wait until it's done since I know it's expensive for the browser.

The browser considers it a bug and that's why it freeze the app and tells you a warning.

The solution: Do not use expensive calculations via actions on too many rows. I'd say that around 100 is fine but more than that takes a couple of seconds which is enough to freeze the browser

[noahbeach82]

So this is an issue when updating or running a process over bulk records.
That kinda stinks. If Appsheet could have actions process in the background
like a cron job that would be great.

[noahbeach82]

I just did a bulk action on 16 records where it was just changing 1 cell in each record. It still froze the app for about 5 seconds. The reason this is an issue is the user will think their app is froze when it is simply processing. It freezes on the confirm action screen so it makes it appear as though it isn't even processing the action and it is just froze.

[MultiTech]

Do you have any select statements that are involved in this process?

[noahbeach82]

Here is a screenshot of the action. 

[noahbeach82]

I don't mind it taking a minute to process a bulk action. The issue is the screen freezing up and it not looking like I pressed the confirm button. It seems these actions need to go into a queue and ran in the background. I could probably do that by creating another table just for job processing and having the jobs run periodically through automation. However, I would have to create a lot of bots to cover about every 15 minutes or so.

[SkrOYC]

@MultiTech is right, you have a bad expression there, think about a way to avoid Filter/Select/Maxrow/etc

Check your schema and see if you can use [Related something] columns to make a better expression.

Filter/Select is the fastest and easiest, which in turn relates to the worst performant

[noahbeach82]

I would probably have to build a new app from the ground up including the back end data. Right now I don't have time to do that, but I may do that going forward. I am not sure how update a record from another table with data from a current table without running it through a filter/select statement first. 

[MultiTech]

What is that select doing... could you show the whole formula?

And the column list for the table where that formula lives, and where you're pulling data from. (This way we have all the column names, and their types, to compare in your formula.)

[MultiTech]

This is an unbelievably deep concept to cover, just FYI.

Ultimately it's a matter of "simplifying" the calculations your app is doing, or shifting "where" they're happening (client side vs. server side).

No "one size fits all" answer for stuff like this...

[noahbeach82]

It is a concept that is actually crucial to app performance and should be conveyed to app developers in the very beginning. I have read about how these statements affect app performance in the documentation. The only hangup I have encountered is in bulk actions though. Frankly if this was being done in a mysql database it would have no problem handling the select statements. However, in this case it can't process them efficiently.

[jyothis_m]

What about doing the Action indirectly through a bot. I think then it should run in the Appsheet Servers. 

Also in one of my Apps i had to enter around 100 rows to a table. I used the Appsheet API for this and the rows were added almost instantly. Don't know whether its applicable in your case. Just in case you can also use the same. It was a game changer for me finding the Appsheet API.

[noahbeach82]

I will look into the API. I have read the documentation before, but haven't considered it. The bot idea has crossed my mind. I would have to really think over how to implement that. I am thinking a table is needed just for updates. The bot would be triggered to run against that data upon updates to a table. Because the update table would simply be inserting a new row of data without filter and select data it may run much faster.

[jyothis_m]

@noahbeach82 what i have done is added a column named Trigger to the existing table. To trigger the BOT i used an Action to add a value (Now()) just to the trigger column of the row. BOT condition is given as [_ThisRowBefore].[Trigger]<>[_ThisRowAfter].[Trigger]

The action button triggers the BOT and the BOT inturn does the other ACTIONS which I think should run on the Servers. 

API is much faster compared to this. 

[noahbeach82]

Thanks for your help. I will actually need to implement this on a bulk inventory process I have which deletes all the scans in a tote. That could be over 300 scans.

[noahbeach82]

Oh man. Have you ever had one of those i'm stupid moments? I just had one. So you guys were right. I simplified the select statement and replaced it with [_THISROW].[Tote ID] and it dramatically sped the process up. I can't believe I didn't notice that the first time. Thanks for your help everyone.

[SkrOYC]

I'm glad you fixed it 😉