Why SubmitForm() would work inconsistently with a list

[rseiler]

I've been noticing some curious behavior with an edit form on which I have a good number of Combo boxes and toggles among some other items like text input boxes.

The data source is a list, and I know that all of the above have submitted fine in testing (actually verified on the list that the changes are made), but I've noticed over time that it's inconsistent.

For example, if I go back in to edit, the first toggle will work while the third one doesn't (by "work" I mean the change is actually written to the list). In the very same session.

I'm testing on the web, so this isn't a situation where it's mobile with a spotty connection.

Are there random elements I need to account for somehow? It's important that I can trust in a submission, since without checking the list, it appears that all is well.

[v-bofeng-msft]

Hi @rseiler :

Could you tell me:

• How did you submit the form? SubmitForm? Patch?
• Have you modified the properties of the controls in the form?(Unlock to change properties)
• What type of control is not working? What are its items? (If any) Does it allow multiple selection? (If any) What type of field does it correspond to in the data source?

Firstly,could you tell me what is  the meaning of 'back in to edit'?Do you mean that after you submit the form, when you modify the form and submit again, some fields cannot be modified?

If so,I suggest you use the refresh function to refresh the data source every time berfor( or after) you submit the form.

I think these links will help you a lot:

https://powerusers.microsoft.com/t5/Building-Power-Apps/Power-Apps-Custom-Forms-not-refreshing-on-ed...

https://powerusers.microsoft.com/t5/Building-Power-Apps/SubmitForm-then-Refresh-does-not-update-data...

Secondly,I made a test but did not encounted the issue you mentioned.If the problem is still not resolved, Could you provide more detailed information?

Best Regards,

Bof

[rseiler]

I'll leave you a complete answer tomorrow, since the answers will take some time and it's late, but for now I just wanted to clarify that I meant: SubmitForm(EditForm1)

[rseiler]

It's not the refresh issue you mentioned (nothing to do with displaying data).

But it is this, which I just discovered today: you can make all the changes you like and submit them successfully. However, that only works once. You can seemingly submit further changes (no errors), but they will not actually write to the list (the timestamp of the list is in fact unchanged).

If you restart the app, you can again make all the changes you like and submit them successfully, but just the one time...until you restart the app, when you can again make all the changes you like.... Etc. Etc.

So, the question becomes: what could cause a condition like that? I think this is better than what I originally thought: a random condition. At least this is predictable.

[v-bofeng-msft]

Hi @rseiler :

I made a similar test but did not encounted the problem you mentioned.

I suggest you try to reset the form(ResetForm function) after submiting it.

Best Regards,

Bof

[rseiler]

That's about resetting the contents of the form, like for use with a Cancel button, but the form isn't the issue here: it's the inability to write to the list a second time without restarting the app. I'm verifying this by looking at the list, not the app.

I can't reproduce it either with a new, dummy test app made from a sample list (this almost goes without saying, since of course it would work, this is basic functionality). I can with the real list and app though.

Perhaps someone has seen this before and knows, out of a million things, what in an app could go "off" to cause such a problem.

[v-bofeng-msft]

Hi @rseiler :

Could you tell me what  the form's datasource and item property are?

I am not sure what caused the problem you mentioned.

If you are willing to try, you may try the following solutions:

1/Use Patch directly to update the data, then reset the form.

2/Save the data to the collection (ClearCollect), and then use the records saved in the collection to update (Patch) your data source. Finally reset the form.

3/Use UpdateIf to update the data and then reset the form.

Best Regards,

Bof

[rseiler]

I've been talking about a (Sharepoint Online) list 100% of the time, so the data source it's set for is the list. The Item property is set to global variable VarRecord.

I've never used those other methods, but I'll look into them if necessary. Patch doesn't sound like a good fit at first glance: "Use the Patch function to modify records in complex situations. Such as, when you do updates that require no user interaction or use forms that span multiple screens."

[rseiler]

It appears that this was somehow caused by the "Too many controls on a screen" warning (deep in the app checker), which is framed as something that relates to performance rather functionality, but maybe there are some edge cases where a performance problem can bleed into other areas, like this, though I don't quite understand how or why.

[NewcombR]

I haven’t been able to replicate this problem. I have a list on one of the apps that has at least 50 columns (I didn’t design the data model...). Typically, I “stage” the data entry for record creation such that the user enters the Title of the SPO record and then submits the record to create the List Item.  This Edit Form form has the default mode of New, so it’s basically a “Create Form” only.

When the user clicks a submit button, I use the SubmitForm function to write the new row to the SPO list.  OnSuccess of the form is set to create a variable to capture the Record of the firm’s LastSubmit property.  The OnSuccess then resets an edit form using ResetForm of a form used on a different screen, and then the Navigate function is used to take the user to the screen.

That EditForm on the second screen is default mode of View, and has its Item property set to an expression that uses a lookup function to get the newly created record stored in the variable. The form stays in View mode until the user clicks  A button that changes the form to Edit mode.

This always works for me without failure.