Answered

Error Messages

(0) Share

Report

Posted on by Pegger

I have an app that I built. At the top of the main screen, the user selects an identifier ID.
All of the radio buttons, dropdowns, etc. are all connected to a SharePoint List and have code in the OnChange property that does a Patch, in which it looks up the correct record within the list to update and then patches the appropriate field....

Patch(Sharepoint_List,

First(Filter(SharePoint_List,ID='ID-Selected'.Selected.ID)),

{Field1:

{Value:'Radio1'.Selected.Value,

'@odata.type':#Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference"}});

The patches work when selected and when I test this out in the studio it does the job. But now when I "Play" the app, I get a ton of error messages that show up when it is started. Most of them are one of these two:

1 - "The requested operation is invalid. Server Response: SharePoint_List failed: Save Conflict. your changes conflict with those made concurrently by another user....."

2 - "Conflicts exist with changes on the server, please reload. Server Response: SharePoint_List failed...."

I find these messages odd because this immediately when I have opened the app, even before I selected an "ID". So I never triggered any OnChange property actions. Any ideas on what is going on here would be appreciated. I don't even know where to start to understand which part of the app is causing this problem. Thanks.

Categories:

Building Power Apps

All responses (5)

Answers (1)

Sort by

RandyHayes 76,299 Super User 2024 Season 1 on at

Like
a
(0)

Report
Copy link

Link copied!
@Pegger

First, just as a matter of performance, change your formulas to the following:

Patch(Sharepoint_List, LookUp(SharePoint_List,ID='ID-Selected'.Selected.ID), {Field1: {Value:'Radio1'.Selected.Value} } )

And you no longer need to specify the odata type on complex columns.

Now...the next point to be made is to be careful with the OnChange actions. On several controls the OnChange action will occur when the Default is set - because the control considers the new default as a change. This is especially notable on comboboxes and dropdowns.

Beyond that, to combat concurrency issues, you will need to check the errors on the datasource in your formula and then utilize the Revert function to revert the value for that record and then patch again.

I hope this is helpful for you.
Pegger 84 on at

Like
a
(0)

Report
Copy link

Link copied!

@RandyHayes
Thanks for that.
I have the default set on all of the controls so that when you select an ID, it will lookup your current selection for that item in the database. This is part of the requirement so I don't think I can get rid of that.

I am thinking that what is happening is that when the app first opens, because there are default values, it is triggering the OnChange actions, but since it has no ID in which to do the Lookup or Filter, it can't find any records to Patch, thus I get these errors. I will see if I can have the App start with an ID pre-selected and then hopefully it won't throw all of these errors.

A few follow-up questions...
1) When (in what situations) do I use First(Filter) instead of Lookup?
2) When using Revert within the OnChange property, I gather I need to say IF it errors, Revert to what is currently in the list for that record, Then Patch again. I could write that once, but what if it happens more than once? Can I create a loop that tries 3 times and then just pops up an error message?
Verified answer

RandyHayes 76,299 Super User 2024 Season 1 on at

Like
a
(0)

Report
Copy link

Link copied!

@Pegger

Actually looking up empty ID's will usually not have any impact.

The bigger issue is that you have (on startup) a control that has a blank value. For some of the controls, once you supply a value, the control will fire its OnChange as the data has changed.

You could certainly do some checking on the ID being blank to avoid the lookup all together, but I believe you will run into the same issue that once you DO finally set the ID, it will lookup, the control value will change and the OnChange will fire. Again, this only happens on certain controls.

For your questions:

1) If you only need one record, use LookUp. If you need a table of records, use Filter. Never use First(Filter!

2) I would reconsider the design and the use of the OnChange all together. This usually gets folks in trouble.

Some options:

A) Consider a "loaded" variable that gets set to true based on a timer control (for so many seconds). In your OnChange actions - If(loaded, Patch....) This would keep any patching from happening until the defaults are loaded.

B) Consider a timer control that every so many seconds will look at all of the controls that need to be patched back. If it finds a change in any control, then patch...otherwise move on. This would get rid of all of the OnChange actions.

Those are just some off of the top of my head.
Pegger 84 on at

Like
a
(1)

Report
Copy link

Link copied!

@RandyHayes
Thanks again for your ideas. I will do some testing on my end to see what options may work best. I had used OnChange because I didn't want the end user to have to hit "Submit" or "Save" button at all. Their work is saved as they go. But I can see that this approach has its drawbacks. I do like your idea on having a timer control that patches every so often if a value has changed. I will look into that for sure. Never used a timer before!
RandyHayes 76,299 Super User 2024 Season 1 on at

Like
a
(0)

Report
Copy link

Link copied!

@Pegger

This is an approach that I have used a few times. Mostly in situations where it was absolutely imperative that any changes were saved because if the app crashed, the device failed, the world came to an end, the data had to be there (or at least that was what the customer thought was important). They did not want a save button (although ironically, they did have a button to take them to another screen...why not save then?)

Anyway, writing back on every character typed (in text boxes) and every toggle flipped, etc. was devastating for performance and...you also hit your app API limits REAL quick!

How I went about that was to create a toggle on the screen (hidden). The default property was set to check the current control values against the underlying record values. Any changes would cause the toggle to go "true".

There was then a timer (set to 10 seconds - was able to convince the client that if the world ended the last 10 seconds of data would not make a difference), in the OnTimerEnd action, it would simply look at the state of the Toggle - if it was true it would do a patch of all the values to the underlying record. If none, then it would skip. It was set to repeat.

Anyway, there are many ways to go about it. Certainly post back if you have more questions or issues.