We are using MS Excel in SharePoint as our source data. Constantly getting the error "Too many requests are being sent … Posted this in forum and to support. Solution was to make sure there were no users editing the spreadsheets. All spreadsheets are locked so no one can open them. Users are getting very frustrated, a lot of time wasted waiting to get onto an app. Testing out moving to Azure SQL as data source currently but not sure that will solve the issue. Its a big move with a lot more expense. Moving to Google is not an option.
we have around 100 users in total with around 40 with permissions on each App. Around 20 very active apps. Maybe 4-5 users active on an app at the one time.
How many rows are you editting at once in your app?
The error you got is related to SPO, not the Excel (Excel is on SharePoint, and that’s probably the reason). If you’d switch to Azure SQL it would solve the problem. But as you said: it’s an expensive option.
As someone who has company partnered with both Microsoft and Google, and someone who is also a Microsoft MVP, and for the sake of saving expenses, I can only recommend () switching to PowerApps in this situation (sorry Google, you know I love you, right?).
I don’t love it and I still know that from AppSheet to PowerApps… uff! What a change!
It’s not just the frontend, the services that work in paralel to AppSheet for it to work the way it does are not easy to replace, I feel like that she can’t affort that change since she’s already an experienced AppSheet creator.
I think that SQL is the way to go, but we all agree that it’s an expensive choice. In my case, I won’t deal with it untill I have 2-3 clients
Trust me, neither do I. Seriously. I;m always against interests conflict between my true admire for Microsoft and Google (yes, it’s possible to love both). The only reason why I mentioned PowerApps is because of thinking through a couple different scenarios (e.g. partialize the batch to smaller pieces. I won’t guarantee it’ll work since I never fiddlered background communication AppSheet ↔ SPO)
Unfortunately, as ex-dev, I can only say that the only way to handle the issue with throttling is by handling HTTP response code and adding time delay. It’s a regular coding stuff.
@MGuzowski , @SkrOYC , I have considered PowerApps. I did look at it before I started using Appsheet over 3 years ago and wasn’t convinced that it could do all that we needed. We have pretty complex Apps. They are business critical apps. Most of the functionality we need can be acheived in AppSheet and our users love it when it works. I may be wrong but PowerApps may be expensive too, not sure you get all functionality with just MS365 licence.
I have set up a free Azure SQL account and created a database. Tried to use the import wizard to import an Excel spreadsheet. After a bit of struggle with a 64 bit v 32bit issue I got our Products table imported and added to an App. The read speeds were hughly improved. Like the way I can use SQL Views also to filter data.
Starting to Copy an App to a database and its been running for over an hour now. I see the tables have been created in the database but still saying - We’re setting up your app.
It would be good to know what size of data you are dealing with.
But even without that, there are a number of things to address to discuss.
100 users is not that many and any single app should handle that easily - let alone those users spread over 20 apps.
20 apps! - If many of your apps share tables, keep in mind that the table will be REPLICATED within each app. So, if you have a large table and that table is used in 10 different apps AND a single user has access to ALL 10 of those apps that will mean that single users device will have 10 copies of that very large table. This can lead to poor performance on the device itself as it tries to manage the data - especially if users are low on internal storage on the device. If you have the case where many users are utilizing several apps that share tables, you may want to consider combining those apps together and use permissions to grant access to the various app features.
“Too many requests are being sent” - I hate to be the one to say it but I want to be as helpful as I can. If you are getting this error, it is likely because the apps are not efficiently implemented with regards to read/write operations of data. For example, it is very easy to create several Bots that end up making the same updates unnecessarily - as just a single example among many.
**"**a lot of time wasted waiting to get onto an app" - I assume this is because of Sync times. The biggest culprit, in my experience, to long Sync times is overuse of Virtual Columns - not data retrieval. You can actually see how much of your Sync time is table reads versus Virtual Column calculations in the Performance Analyzer under the Manage tab. Many believe this, slow Sync times, can be overcome by switching to a database. Probably not. Virtual Column calculations are performed on the server after retrieval of data. If those calcs are already a majority of the Sync time the app would NOT see a marked improvement in Syncs.
I do have personal experience with AppSheet apps using Excel on Sharepoint. Based on my limited exposure, it is not a good combination. A database will definitely help speed up the data read/write portion of your apps.
However, from your description of the issues, my concern is that there are other areas within your “system” of apps that may also need some attention to improve read/write frequency and Sync times. It is not an easy process to go through and sometimes it is best to simply re-write the apps, taking all the knowledge you have learned along the way and giving it a fresh start!
We are a construction firm so we have an App with the same structure for each project but different data. Our biggest table is our Master Products table which is shared among all Apps but there is a security filter to only bring in the products specific to that project. Suppliers and Users are our only other 2 global tables. See below for rows and columns. Typically those using mobile devices only access 1 App (our site teams). Our Procurement and Accounts teams are office-based and would use all Apps.
I have went through the app with a fine toothcomb removing everything possible. Pretty complex app so need the functionality. Users are still asking for more additions and I have had to say no at this point. I spent an hour with Matt at Multivisions going through all possible things to check in case I had missed anything but came up with nothing new. Also spend another hour with Simon at 1MinManger. Sync times are also a big issues along with Too Many Requests issues. Looking at the performance log, it is the time it is taking to read the tables rather than the virtual columns.
Its almost midnight here in UK and copying App to SQL database has been running for about 2 hours now. Not sure if I should just let it keep running.
Started to copy App to SQL around 9pm UK time on Thurs. At midnight it was still running. The tables seemed to be being created so I let it run and went to bed. Woke about 3am and it was still setting up the app so I closed it. Looked at it this morning and the app was created. Seems like the only table not copied was my Users table. Tried to use the function - Copy Data to New Source and got this error. Anyone know what this means?
That is a generic JSON error message for uncommon errors - such as a partially built table that was stopped in the middle of its copy process. Just kidding - I would have stopped it too!
First, make sure you have a data backup.
I suggest to check the table in the database and manually adjust/add any of the columns. If any data was copied, I would remove it to start with a blank table. Then try the “copy data” function again.
If it still doesn’t work, there is usually an Import function in the database tool. You can manually export the data into a CSV file and then use the table importer to import from the CSV file.