So my own personal approach has been that instead of calling the main table to display (say firstly in a gallery and then the selected record in data cards) I use a database view (which poweapps now supports). Even if the view is just all unfiltered records and all columns from your table (i.e. identical to your core data table) to begin with. There main advantage here is the ability to control what information powerapps sees, but to do it from the database side. So for example...
If you ever want to soft delete a record you can add a simple bit column (isDeleted) into the table, but change the view so it filters out any of the deleted records (i.e. where isDeleted <> 1) and this way you never need to put that logic into your powerapps gallery filter.
Or if you want to join info from another table on, you can do this in the view without having to add and store additional field data in your core record.
So assuming you have your view set up and this is what's coming into.your gallery and being displayed in your sections, you just need to decide exactly how you go about the editing process for the users. But however you want to do this you need to make sure you create a SP in the database that accepts the parameters you want. So let's keep it conceptually simple, we create a SP that accepts parameters for each field you might potentially want to edit in an update. Let's say this is proc_tableUpdate. All parameters are set to NULL maybe which gives you the option of passing only changed values of the record. However if you want to pass over all values to the procedure that's not a problem it's just a case of whether you want to limit the data going across.
Your SP should just effectively be a UPDATE statement. It takes the values you pass it and updates the core record table (and does whatever else you want it to e.g. create an audit record of the change)
To access this SP from Powerapps you need to set up a flow from your powerapps home page, look for the Execute SQL Server stored procedure connector, and then if your gateway is up.and running correctly you should see your SP. the final set up for the flow will ask you to define the parameters but you click on "ask in powerapps" for each parameter space. You can assign a flow to an ON SELECT action in Powerapps, and you then give it the values from your powerapps items, such as drop downs, input boxes etc. The point is here that there are a million and one ways of designing this kind of interface then, and it just depends on your preferred way if setting it up. But ultimately the desired values go.into the flow as parameters and are therefore passed through the gateway to the SP as such.
So things I didn't touch on there are adding new records:
You can either do this using the same SP but use a MERGE function to distinguish between an update or an insert (or you can manually simulate this but SQL server's merge function is pretty valuable)
OR you can set up a separate SP (with an insert function) and flow to handle the insert of a new record of your PA process is different for updates and new records.
The other thing is that eventually you may just want to pass through a single string to your SP and come up with your own logical delimiting syntax to allow you to pull it apart the other side.
Hopefully this is a little help but suspect you'll still be searching around the forums for more info on things, because I've probably left a tonne of gaps in the process. The more I've delved into PA the more I've decoupled the Data handling from PA's own mechanisms and used flow to hand the data to the DB to process. As good as they are, I prefer the flexibility of SQL server in the long term, but this makes PA so much more straightforward and useful from a user front end builder.
