is there a pattern for using database "rowversionid" for PowerApps

[tutor]

is there a pattern for using database "rowversionid" for PowerApps (recognizing that this is going to be a little different for each database vendor), let's start out with SQL Server

basic premise is that there needs to be a 101 means of handling concurrency

is this a json call? encoded base-64? anything prebuilt?

what if I bump into a row which has already been updated? is there a pattern?

Thanks

Rob 

[RandyHayes]

@tutor 

Your datasource will have an error if you try to update a row that has been updated by someone/another process.

From that, you can get the Error using the Errors function and then determine the best course of action.  One option is to Revert the row and then adjust as needed.

I hope this is helpful for you.

[tutor]

Our scenario is pretty complex.

Let's say we have an object in the database called "Pricing".

User A is only changing a single price (US state based) and does it quick. User B who's been working on that same row for the last half hour, needs to do what? (a. loose a half hours worth of work; b. be notified that their changes can't be posted and a reconciliation process is going to refresh the screen/data, field by field, merging the two (in this case, just a single change from User A)

So do we have any kind of pattern for "B" out of this scenario?

(Of course in real life there could be lots of scenarios, including batch jobs changing data where only the rowversionid would indicate that the data wasn't "fresh". Again, is there some sort of pattern for reconciliation? I've handled this from lots of "high" code platforms, but never a "low code" product like this.

[RandyHayes]

@tutor 

Yes, the answer I mentioned before is your no-code way about it (PowerApps is no-code, not low).

The only recourse you have from the PowerApps perspective is to detect errors with the Errors function and the Revert changes with the Revert function.  

Take a look at the Revert function in the docs as it give a description of that same scenario you state.

Keep in mind that PowerApps is not a real-time platform.  When you start the app it captures a session table of your data and works with that from there on.  If other people are changing the real data, your session table does not update unless you issue a Refresh or a Revert.

So...if you Revert a record because it failed due to concurrency you can then decide how you want to "capture" the information entered from User B and then merge/replace with the reverted record.

[tutor]

I guess the next question is, if I have a session table (let's say Pricing) being offered in a grid, and I go to edit a single row, can I work in that context (single row) for the edit?

(Sorry, relative newbie with PowerApps, to the point where things that come as being "basic" (in Java, .Net, etc.), have to be re-thought/architected.)

Rob

Rob

[RandyHayes]

@tutor 

Yes, leave all of your developer knowledge at the door.  PowerApps is a no-code platform that is built around the concept of formulas just as you would do in Excel.  It is referential not declarative.  If you think like a developer, you will struggle with the platform.

As for the editing, yes, when you have a gallery of records and select one to edit then you will be editing that one record.  However, there is no concept of record locking in PowerApps, so there is nothing that precludes anyone else from editing.  

That level of "real-time" is left for developed applications. 

As mentioned, PowerApps will gather records into a Session Table (not accessible directly) that is in your cloud session.  It is a snapshot!  It does not refresh unless you refresh or revert. The app then gets its information from that session table as needed.  This happens in all instances of the app. 

So person A could start the app and get a data snapshot at x time.  Another starts later and gets data a y time.  If any users are editing and saving the same record, there will be concurrency issues.

SO...bottom line, PowerApps is not designed to be a real-time data entry system.  It has minimal abilities to do any sort of concurrency checking and none for record locking.  All of these can be "designed" into an app in some form or another, but performance will be poor in many cases and it is not a trivial task.

[tutor]

OK, thanks Randy   

The platform my customer wants to migrate from is Access, so they are familiar with the "data has changed" on postback scenario.

I'll spend a little bit of hands on time and kick it around. (Will looking at the functions you mention and maybe see what ajax capabilities might be available too 🙂

Rob

[RandyHayes]

@tutor 

No problem!

There will be no Ajax capabilities in PowerApps.  You are limited to what is available to the platform as it is a no-code solution.

The concept of the "data has changed" on submit is pretty much what I mentioned before...submit, get error, revert, replace.  It's not trivial but it is possible to implement in PowerApps.

[tutor]

we are trying to do this kind of stuff via a Flow now.

this is kind of important for us, since this means we can do tons of transaction-type stuff now in Power Suite. (Like run a stored procedure and get a return code, call a stored procedure which is returning the data from many sources (i.e. linked servers), run a web service (like SSRS), call a whatever externally 😊

trying to investigate some options:

https://powerusers.microsoft.com/t5/General-Power-Automate/Need-to-use-another-User-s-connections-on...

https://powerusers.microsoft.com/t5/Building-Flows/Running-flow-with-different-user-s-credential/td-...

https://docs.microsoft.com/en-us/sharepoint/dev/business-apps/power-automate/guidance/manage-list-fl...