Server Response ETAG mismatch (Conflicts exist with changes on the server, please reload)

[Anonymous]

I've been having this error since last week and it was working fine before. 

I can't update my SharePoint list when I press the "Yes", ETAG error appears.

It happens when I update/select/choose a Leave Type and patch the LeaveTypeList Column on the LeavDateSourceSelected.

Same thing happens when I update the Approver Column.

I'm not sure if PA has to do with it or a SharePoint error.

Any idea will be helpful. 

Cheers

[Anonymous · Accepted solution]

Fixed the problem!

I inserted the Refresh(DataSource) Function before the final patch.

On "Yes" Button:

UpdateContext({ showLoader: true});
Refresh(LeaveForm); I added this.
Patch(LeaveForm , LeaveDataSourceSelected,
{
LeaveTypeList: NewLeaveTypeList,
Approver: EditRequestItem.Approver,

});

On "Save" Button:

UpdateIf(LeaveRequestSelectedCollect ,LeaveTypeList <> EditLeaveTypeGallery.Selected.type, {LeaveTypeList:EditLeaveTypeGallery.Selected.type});

Instead of using Patch on the "Save Button" I used UpdateIf Function.

After changing the codes. Save and close your application and Open it again.

Cheers

[MiraGhaly]

Hello,

I am facing the same issue and i tried refreshing the data source before patch and it is not working:

I am actually doing bulk update:

ForAll(

processedLineItems,

Patch(

'Supplier Invoice Data',

LookUp('Supplier Invoice Data', ID = processedLineItems[@ID]),

{Status:{'@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference", Value: "Portal Upload"},DataReadyForUpload:true,Portal_x0020_Reference:Concatenate("Portal Reference _",Text(Now()),"_Submit")}

)

)

ِAlso i am doing Individual Updates on Items in a gallery:

Patch('Supplier Invoice Data',ThisItem,{To:ToDate.SelectedDate})

[Anonymous]

Hi,

Have you tried using UpdateIf Function?
On the screen property OnVisible,

Set(ProcessedLineItemsID, processedLineItems[@ID]))

ForAll(

processedLineItems,

UpdateIf(

'Supplier Invoice Data', ID = ProcessedLineItemsID,

{Status:{'@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference", Value: "Portal Upload"},DataReadyForUpload:true,Portal_x0020_Reference:Concatenate("Portal Reference _",Text(Now()),"_Submit")}

)

[luuminhvuong93]

Adding the Refresh Button make the app run longer for about 10 seconds 😞 not ideally

[Anonymous]

I can't get my SharePoint list to update after attempting to fix that ETAG error.

At first I had this on my Screen's OnVisible:

Refresh(SpTable);
ForAll(ClTable, Patch(SpTable, LookUp(SpTable, true), {index:index, power1:power1, power2:power2, (…)}))

And I changed it to this:

Refresh(SpTable);
ForAll(ClTable, UpdateIf(SpTable, true, {index:index, power1:power1, power2:power2, (…)}))

ClTable is a collection table, SpTable is the SharePoint one. Both have same columns but since PA was complaining about not being able to modify "Modified" column I told it to update only specific columns. It kinda works when I use Patch, but it skips random records, but with UpdateIf nothing gets updated. All records must be updated, hence why I used true as condition.

Any help would be appreciated.

[luuminhvuong93]

Added the Refresh data source slow the whole thing down significantly,

Is this a Sharepoint issues, ot Powerapps issues ? 

[rseiler]

That wasn't a rhetorical question in the last post. Anyone know?

Especially since a refresh isn't necessarily the fix.

[Reigningfear]

I have been experiencing this issue as well lately. Prior to this, I plugged in a refresh before the creation of an item in my SP list (using submitform) and while the additional time to refresh wasn't ideal, it was working. Recently, the refresh prior to submitform is still presenting an Etag error during the creation of an item. However, within the same session, I can edit the item I just created with no Etag error. It's worth noting that I have a refresh plugged in prior to the patch operation for editing the item. The creation of the item does seem to go through successfully despite the error. 

I think it's worth noting that I do have 4 successive patch operations during the creation of the item, in case that is part of the issue. 

I haven't been able to identify a specific pattern thus far as in previous weeks, I observed it occurring during editing and creating. Any ideas/workarounds are certainly welcomed.

Edit - Using the performance monitoring tool, I seem to have narrowed it down to two specific patches. One patch has a switch statement within it and the other one is a normal patch. The submitform and first patch seem to go through successfully. I'll edit this after a little more experimentation.

Edit 2 - After using the performance monitor, I identified that all of my patches after the refresh were failing. After more testing, I found that the refresh was in fact causing the ETAG error, perhaps due to the placement. My previous code was:

if(form.valid=true, submitform(form));
refresh('database');//My thought here was refresh it to make sure it is patching the latest "version" of the item. 

patch(database,form.lastsubmit,"patch data");

patch(database,form.lastsubmit,"patch data");

patch(database,form.lastsubmit,"patch data");

I am guessing the refresh after submitform was messing with the "lastsubmit" portion of the patch. It seems to be functioning normally now after removing the refresh.

[rseiler]

We're doing the same thing, a refresh before submitform, but in our case that never helps--but I think I know why. For whatever reason, submitform isn't waiting on the refresh to complete. I think it's rushing ahead and happening too soon, and I know this because I took the refresh out of OnSelect and put it in a separate button for testing.

So, when I want to submit a second time, I click that Refresh button first, it does its thing, and then I click the submit button. That works every time.

While the real solution is to find why a refresh is needed in the first place and work around it properly, finding a way to introduce a delay between your refresh and submit would be another solution. Having a separate button was just for testing.

[Reigningfear]

That's interesting. Thanks for the additional insight. I edited my last post but will mention that it might help to check the performance monitor. It flagged the row where the etag mismatch happens, for me at least. I'll be editing my post with my findings in case it helps someone.