Patch with Sharepoint not working for certain users.

[Anonymous]

Hello:

I would appreciate any assistance troubleshooting. I made an app with a patch function that searches for a Sharepoint list row and modifies it, below. This code has been working consistently for several months. As of last week, certain localized users at one location consistently can no longer save. 90% of users using the same app at other locations can still save consistently. There are no delegation warnings and if there were, all users would be affected. 

There is also code that would prevent execution if the row index could not be found for the patch operation. But this code IS returning items so the validation is not triggering 'true' in the 'mandatoryNotFilled' boolean..

UpdateContext({resultTest:Filter(SPList, Title=TextInput10.Text)});

If(CountRows(resultTest)=0,UpdateContext({mandatoryNotFilled:true}));

If(mandatoryNotFilled=false, Patch(SPList, First( Filter( SPList, Title =TextInput10.Text)), {

//patch fields here

}));

The code below, without the filter, still works for ALL users. Therefore the 10% of users who cannot save must have access to the Sharepoint list and can patch.

If(mandatoryNotFilled=false, Patch(RAWebDataArchive,{
//patch fields here
}));

TLDR:

-Users can connect to a Sharepoint list I want to patch to

-Filter is finding the row that's supposed to be patched

-The code is working for other users

-Non-filtered patch is working for affected users

-Patch is still failing.

I'm stuck. Does anyone have ideas on what to troubleshoot next? What could cause a localized problem such as this?

[Anonymous]

Edit: I just realized the affected users are from Korea/Japan. are there any known issues with recent Powerapps or Sharepoint updates affecting the saving of special characters? That would explain it.

[v-siky-msft]

Hi @Anonymous ,

I haven't heard any update or bug about the special characters issue. Do you mean the Korea/Japan user filter the list by special characters? Is there any sample data?

How many rows does the list have? I'm not sure this is a Delegation issue, but it's worth considering as the UpdateContext function isn't delegable, so the resultTest can only retrieve back the first 500 rows(by default). If user try to search the record 500 rows, the resultTest would return empty.

You can increase the data limitation from 500 to 2000 in advanced settings to avoid this delegation issue if the list has less than 2000 rows data.

Hope this helps.

Sik

[Anonymous]

Thank you; the list does have more than 2000 items but I've ruled out that filter as a problem.

I've also ruled out special characters; two people in the same region and on the same network get different results.

I'm still looking for a solution; maybe it's a caching problem?

[v-siky-msft]

Hi @Anonymous ,

Apart from the cache or browser issue, the data permission of data source should be also be considered. Maybe these users with issue have different data permissions from others.

Hope this helps.

Sik

[Anonymous · Accepted solution]

Hello:

I found the issue! It was my fault for not providing the full code above - lesson learned.

The code is like this. The red highlighted field refers to a TextInput field with the following value:

Text(editFile.mdDateTime1, "[$-en-US]dd-mmm-yyyy hh:mm AM/PM")

Basically, it converts a date value to text, then saved it back to the Sharepoint list as a date again.

If(mandatoryNotFilled=false, Patch(RA_Data, First( Filter( RA_Data, Title =TextInput10_18.Text)), {
Title: TextInput10_18.Text,
mdDateTime1: DateTimeValue(TextInput14_18.Text),
mdDateTime2: timeNow,
mdText3:Dropdown9_18.Selected.Value,
mdText1:TextInput6_20.Text,
mdText2:TextInput1_18.Text,
paText9:TextInput7_21.Text,
paText2:TextInput7_22.Text,
paText1:TextInput7_23.Text,
paText7:Dropdown7_18.Selected.Value,
paText8:TextInput11_18.Text,
paText3:TextInput7_75.Text,
paText4:TextInput8_18.Text,
paText10:TextInput12_20.Text,
paText11: TextInput12_37.Text,
paDate1:DatePicker11_18.SelectedDate,
paDate2:DatePicker12_18.SelectedDate,
paDate3:DatePicker13_18.SelectedDate,
paDate4:DatePicker14_18.SelectedDate,
paDate5:DatePicker15_18.SelectedDate,
paFreetext1:TextInput13_18.Text,
t3:Dropdown8_30.Selected.Value,
t4:Dropdown8_39.Selected.Value,
t5:Dropdown8_62.Selected.Value,
t6:TextInput2_14.Text,
t15:TextInput1_23.Text,
ft1:TextInput2_10.Text,
ft2:TextInput2_16.Text, ft3:User().Email,
d1:DatePicker1_25.SelectedDate,
d2:DatePicker1_43.SelectedDate,
d3:DatePicker1_44.SelectedDate,
d4:DatePicker1_45.SelectedDate,
d5:DatePicker1_64.SelectedDate,
paRad1:Radio1_18.Selected.Value,
CloseMark:If(Dropdown9_18.Selected.Value="Withdrawn"||Dropdown9_18.Selected.Value="Cancel/Delete"||Dropdown9_18.Selected.Value="Approved/Cleared"||Dropdown9_18.Selected.Value="Assessment Complete"||Dropdown9_18.Selected.Value="Converted","x","y")
}));

What was happening was, something changed around approx. 7/30/20 in the way Powerapps does the text-to-date conversion or the DateTimeValue conversion worked. The code did not change.

For end users with non-US date formats, the DateTimeValue conversion started failing, (it was working before 7/30 for the same users and code). This conversion error prevented the Patch function from activating; because the Patch failed, it never sent a request to Sharepoint, and so Sharepoint never sent any detectable errors back.

It works now that I have removed the DateTimeValue coversion.