Sync problems and users disappeared from user monitor

[Nicklipov]

Hello!

I have a problem with syncing my App.
The problem appeared about month ago - sometimes adding a new row took about 180-210 seconds.
Today the problem became bigger - every “add row” operation take 180-210 seconds.
My users make about 200-300 new rows per day…

I’ve tried to delete old rows (about 8000 rows) and some app functions, now the app’s goal only to add rows in two tables.

I receive two types of errors:

1. “Error: Data table ‘the_name_of_the_table’ is not accessible due to: The operation has timed out.”
2. “Unable to add/edit/delete row in table ‘the_name_of_the_table’. → Too many users are attempting to modify the spreadsheet ‘DocId=some_doc_ID’ at the same time. Please try again after a few minutes.”

My offline/Sync options:
Sync on start - off
Delayed sync - off
Automatic updates - on
The app can start when offline - on
Store content for offline use - off
Server caching - on
Delta sync - on

Do anyone know - what should I do to sync faster? Is there is any way to reset changes to every devices?

Also a lot of users have disappeared starting from December.
Actual amount of users should be about 160 - 180 users (most of them are “guest” users).

[GreenFlux]

@Aleksi, @Steve, do you guys know what the By User -1[-1] means? I’ve also seen this in logs before on an app that requires login.

There should not be any guests accessing the app, so why does the log not recognize the user?

[LeventK]

@GreenFlux
Here you can find @Phil’s explanation for that:

Audit Issues Questions

We report -2 in the Audit History until your authenticated user grants permission to use their actual user id.

[Steve]

Nicklipov:

sometimes adding a new row took about 180-210 seconds.
Today the problem became bigger - every “add row” operation take 180-210 seconds.
My users make about 200-300 new rows per day…

The most common cause is that you have too many virtual columns and/or at least some of your virtual columns require extensive computation. All virtual column values are recalculated at every sync, and will directly affect sync time. The larger your data set and the more complex your virtual column app formulas are, the slower your sync times will be.

Nicklipov:

“Unable to add/edit/delete row in table ‘the_name_of_the_table’. → Too many users are attempting to modify the spreadsheet ‘DocId=some_doc_ID’ at the same time. Please try again after a few minutes.”

Are you using an Excel spreadsheet?

help.appsheet.com

Using Data from Excel spreadsheets in Office 365 and SharePoint

How you can build an AppSheet app with data from Office 365, Excel, and Sharepoint.

With Office 365, if a user has the spreadsheet open for editing, other users and third-party apps like AppSheet can’t make updates to the spreadsheet. Consequently, if you intend to build an app that updates the data (as most apps do!), please make sure to close the spreadsheet first. Otherwise, you’ll see conflict (“409”) error messages and the app won’t be able to save changes to the spreadsheet.

See also:

help.appsheet.com

Limits on Data Size

How to design your app with consideration of caching and intermittent connectivity.

[Nicklipov · Accepted solution]

I’ve figured out the sync problem.
Deleting virtual columns was my first step even before posting this problem.

I’m using Google Spreadsheet and my spreadsheet isn’t going to exceed file size limits.

I’ve checked my performance profile and noticed that the App reads some spreadsheets very fast but one spreadsheet took 3-5 minutes to read.
I’ve checked this spreadsheet and even reading it by Google Chrome or Google Office Spreadsheet App take some time and “calculating formulas…” progress bar is shown permanently.
The spreadsheet contained a sheet with a lot of formulas. Deleting this sheet fixed the sync problem.

In short, slow sync time can be caused by spreadsheet with a lot of formulas in sheet even this sheet is not performed in your App.

[Steve]

Excellent catch! Well done!

[OptimiX_XcrY]

Hi there,

All of my users started seeing this error today, about multiple table, not about the same. 

Any chance this could be the result of another engine update unannounced?

I checked all the usual, no updates on my side, and 10 times less cells than in December.

All users work seems to be lost today.

 thank you

 

[Eliecer]

@Steve hi man, how can i solve this problem?