New Bug Encountered:Data table not accessible due to "Internal Error" with all Office365 apps

[GreenFlux]

One of my accounts is getting the same error in two different apps- both using Office365/Excel as a datasource.

There are many other tables but the error only mentions one being inaccessible. I’ve tried clearing cookies/history, different browser, tablet, etc.

[MultiTech]

One thing to check is if the Expense file is open somewhere; I see you’re using Office365 and with that data source the file can’t be currently being edited by someone when the app tries to access it.

But in cases like this, you should email support@appsheet.com for direct support.

[GreenFlux]

Thanks @MultiTech_Visions. I have noticed that as well with Office365 Excel files getting locked. No one else has access to the sheet in this case though.

I’ve emailed support already but thought I would also try here in case others are experiencing issues with Office365 data sources this morning. It’s affecting backup copies of the app under the same account as well.

[Kyle_Richardson]

I’m having the same issue this morning.

[GreenFlux]

Thanks @Kyle_Richardson. Glad to hear it’s not just me.

[GreenFlux]

@Kyle_Richardson,

1. are all of your apps affected?
2. are all of your apps using Office365/Excel as a data source?

In my case, the account uses an Office365 login, all data sources are Excel files in that Office365 account, and both apps in that account are getting the same error.

However, I was able to copy a sample app using Office365/Excel as the data source, and everything worked fine.

[Kyle_Richardson]

I have my current live app and an upgrade to it that I’ve been working on separately that are affected.

All associated Excel files are stored on SharePoint with O365.

[Appsheet-GLM]

Same issue here…

[Eleshia_Robinso]

Same issue for me too!

[pravse]

Looking into it right now! Sounds like it is Office365 accounts only. Could you confirm please?

[GreenFlux]

Sounds like SmartSheets is having a similar connection problem.
https://community.appsheet.com/t/smartsheet-error-apps-not-able-to-load/13440/4

[Eleshia_Robinso]

I only have one app and it uses O365. Now I am getting a different error that may help:
Error: Dat table ‘Crossings’ is not accessible due to: Error code: DeploymentInvalidEditSession Error message: There were communication or server problems and you are no longer connected…

[pravse]

It might be an O365 API issue. See https://downdetector.com/status/office-365
We’re continuing to investigate

[pravse]

We think it is an Office365 API issue. Our code is (unexpectedly) not getting back any data when reading some of these sheets from the Office365 API. This is causing internal errors in our code, which is what you see reported. The problem started happening around 1AM PST today — no change at that time on our side, but probably some change in Microsoft’s service.

Resolution unclear, but no immediate solution from our side unfortunately.

[pravse]

One more update: the problem doesn’t seem to occur for all sheets on Office365. Just for some. For example, for @GreenFlux, the problem is only with one of the sheets in the app (the ‘Expenses’ sheet). There may be something specific going on with some sheets (perhaps a special formula or something) that is causing the Office365 Excel API to break.

[pravse]

@Kyle_Richardson in your app, ‘Pour’ and ‘PourDate’ load fine. But there is a problem with ‘ProductionLog’. Is there anything special about that table?

[Kyle_Richardson]

@praveen It does contain a couple necessary spreadsheet formulas. They worked fine up until this morning.

[Sakis_Koukouvis]

For me the problem is for only one sheet.
It is a table with many necessary columns.

[Eleshia_Robinso]

My app is reporting the issue on 2 of the many sheets in that workbook. Neither of these sheets have any Excel formulas. Here are some of the statistics on those two sheets:
Attachments Excel sheet

• 11 columns
• 20657 rows of data
• no formulas in the Excel sheet
• Some virtual AppSheet columns for this table (total of 16 AppSheet columns)
• Some AppSheet formulas like
  LOOKUP([PoleID],“Poles”,"_PoleID",“Segment”)
  CONCATENATE([Height (ft)],"’ “, [Height (in)],”""")

Poles Excel sheet

• 39 columns
• 6837 rows of data
• no formulas in the Excel sheet
• Lots of virtual AppSheet columns for this table (total of 51 AppSheet columns)
• Some AppSheet formulas like
  IF(COUNT([Related Violations])=0,“None”,“See Violations Section”)
  IF(COUNT(SELECT([Related Violations][Violation Category], [Violation Category]=“Power”))>0,“YES”,“NO”)
  LEFT([Inspected By],FIND("@",[Inspected By])-1)

[Kyle_Richardson]

I have 6 other tables that contain multiple REF columns pointing at the table in question.

95 columns total in the ‘Production Log.xlsx’ table.

Spreadsheet Formulas -

TotalShippedQty: IF(OR(RC[-24]=“NA”,RC[-24]=“N/A”,RC[-24]="",RC[-24]=0),"",SUMIFS(‘Shipping Log’!C[-23]:C[-23],‘Shipping Log’!C[-26]:C[-26],RC[-24],‘Shipping Log’!C[-17]:C[-17],“Y”))

MoldsMade: IFERROR(SUMIF(Molding!C[-17]:C[-17],RC[-19],Molding!C[-12]:C[-12]),0)

OrderComplete: IF(RC[-76]=TRUE,VLOOKUP(RC[-75],C[-82]:C,83,FALSE),IF(OR(RC[-58]>=RC[-73],RC[-1]=“TRUE”,RC[-1]=TRUE),TRUE,FALSE))

[pravse]

Yes, our logs show that this problem started around 1AM PST today. No change on our side at that time (or over the weekend). This is definitely something (probably an internal bug) on the Office365 side. So now we’re down to trial-and-error to see what might be causing the problem and how to work around it.

We are still looking for workarounds in our code (by finding some alternative API). In the interim, we are also looking for any insight any of you may have about what could be special about the spreadsheets that are failing.

[GreenFlux]

@praveen, there are no spreadsheet formulas in the sheet that is failing (or any of the other sheets for this app). I’m using security filters, but so are the other tables in this app. The main difference, in my case at least, seems to be the size of the table.

Perhaps the Office365 API was updated with a lower limit on data size, or the request timeout was shortened and these larger tables don’t respond in time.

[pravse]

We think we my have a workaround by going temporarily to a much older API. It will be slower but the apps seem to at least load. Not sure yet if all the update use cases will work. We’re currently running through a quick set of tests before deploying it.

[pravse]

Hmm, so it is a larger table. That is an interesting observation.

[Kyle_Richardson]

My table is large as well. 90+ columns.

[pravse]

We’ve deployed a workaround. Could you check please?

[Appsheet-GLM]

it doesn’t work for me

[Appsheet-GLM]

Ok the apps are back in service now! Should we see a difference on app performance?

[GreenFlux]

My apps are back up as well. Thanks @praveen!

[Eleshia_Robinso]

My app is working now. I had un-sync’d changes before the issue began. Now those have sync’d. Where would we expect to see the performance degradation caused by the use of the old API? The syncing of the records is excruciatingly slow. It didn’t seem to be this slow yesterday.

[Sakis_Koukouvis]

No, me 3 apps don’tt work for me (user: landscape2@fiva.gr)

[Mauricio_Bick]

Apps working so far…Thank you!!

[pravse]

yes, app sync will be a lot slower than before.

As a frame of reference, this is like a time machine. The performance you are seeing now is what it used to be about a year ago before we moved to the newer/faster Excel API. That’s the API that is broken today.

@Sakis_Koukouvis could you please send the details of your app to support@appsheet.com, indicating that it does not work for you despite the deployment. Thanks

[Sakis_Koukouvis]

Hi,

I jave just sent email to support@…

[Eleshia_Robinso]

I may have confirmed too soon. My initial test after your deployment was on my PC in the config environment (not sure what you call the web area where we see the app running on the right side of the screen). I’ve started testing the update from my phone.

I deleted ONE record (that has associated records in other Excel sheets) through the app and tried to sync. Saving Changes(1/1) appeared and sat with no activity (no progress bar) for about 9 minutes. Around 9 minutes of waiting, I finally saw the white progress bar begin to move across the screen. And at 10 minutes, the sync completed.
In trying another test, I made a change to 1 field for a record. This time, the Saving Changes (1/1) sat on screen for only 3 minutes, followed by an app sync.
In my final test, I wanted to confirm the length of time for the delete record function. After 2 minutes, I got a message on screen that says “Connection timed out. Please wait a moment and try again.”
This will be completely unworkable if a user has more than one record to affect at once in multiple tables (foreign keys).

[pravse]

@Sakis_Koukouvis your account was explicitly added to the API (you were one of the first customers we upgraded to help with your performance). That’s why our rollback to the older API today didn’t affect you.

We’ll add you to it to get your apps to run again, but it’s going to run VERY slow.

[Tim_Martin]

@praveen - my app is now online too.

[Kyle_Richardson]

@praveen

My app is online now.

However, it’s only reading the one of ~2000 records in the main table.

[pravse]

@Eleshia_Robinson and @Kyle_Richardson please send your app details to support@appsheet.com and indicate that @Harry should look at them.

I don’t know if we will have any good news for you. As I told you, this is an old and inefficient API we have reverted to as a workaroiund to at least unblock the apps running. In the meantime, we have escalated to various people at Microsoft where the actual source of the bug is. This is Microsoft — I don’t know what response times to expect.

[Appsheet-GLM]

MAJOR ISSUE, we cannot synchronise if the Excel Spreadsheet is open on a computer.