Changes to Gallery not saving when modified

[aakk9911]

I have a Canvas app so that users can allocate hours to projects they are working on. On the initial save (when Save button is clicked), the patch works well and it is written to the list. However, if any changes are made to the already existing gallery item, any subsequent changes are not saved to the SharePoint list.  I am noticing that the values revert back to the initial save.  I have a total of three buttons in play here with only one being visible to the user, the Save button.  Here is the expression I have on it's OnSelect property:

Set(
    varResult,
    Patch(
        ProjectTimeTrackerv2,
        ShowColumns(
            colGridUpdates,
            "StartDate",
            "EndDate",
            "NumberOfWeeks",
            "TotalHours",
            "HoursPerWeek",
            "ProjectLookup",
            "Manager",
            "DCIO",
            "Resource",
            "ID"
        )
    )
);
Select(Button6_1);
Notify(
    "Your hours have been saved!",
    NotificationType.Success,
    3000
);

Here is the expression I have for my Button6_1 button:

ClearCollect(
    colGridData,
    Filter(
        ProjectTimeTrackerv2,
        ProjectLookup.Value = RecordsGallery1.Selected.Project
    )
);
Clear(colGridUpdates);
Set(varReset,false);
Set(varReset,true);

Lastly, here is the expression I have for my last button, Button4_1, which is located directly within my Gallery:

If(
    IsBlank(
        LookUp(
            colGridUpdates,
            ID = ThisItem.ID
        )
    ),
    Collect(
        colGridUpdates,
        ThisItem
    )
);
UpdateIf(
    colGridUpdates,
    ID = ThisItem.ID,
    {
        StartDate: startDate.SelectedDate,
        EndDate: endDate.SelectedDate,
        TotalHours: Value(TtlHrsPerWeekLbl.Text),
        NumberOfWeeks: numWeeksLbl.Text,
        HoursPerWeek: txtHrsAllocated.Text,
        Manager: txtMgr_1.Text,
        DCIO: txtDCIO_1.Text,
        Resource: {
            '@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
            Claims: "i:0#.f|membership|" & resourceCB.Selected.Mail,
            Department: "",
            DisplayName: resourceCB.Selected.DisplayName,
            Email: resourceCB.Selected.Mail,
            JobTitle: "",
            Picture: ""
        }
    }
)

Any guidance would be greatly appreciated!

[poweractivate]

@aakk9911 

Where is Button4_1 used from your existing formula? I didn't see a Select(Button4_1)

[aakk9911]

Hi @poweractivate,

Great question.  I have a 'Select(Button4_1)' formula assigned to the OnChange property to the input fields within my Gallery.  For instance, if Resource, Start Date, End Date, or Hours Per Week is changed, the OnChange in each of those fields will trigger Select(Button4_1).

[aakk9911]

I've tried including a ForAll function in my Save button OnSelect property, like below -

Set(
    varResult,
    ForAll(
        colGridUpdates,
        Patch(
            ProjectTimeTrackerv2,
            LookUp(
                ProjectTimeTrackerv2,
                ID = colGridUpdates[@ID]
            ),
            {
                StartDate: colGridUpdates[@StartDate],
                EndDate: colGridUpdates[@EndDate],
                TotalHours: colGridUpdates[@TotalHours],
                NumberOfWeeks: colGridUpdates[@NumberOfWeeks],
                HoursPerWeek: colGridUpdates[@HoursPerWeek],
                Manager: colGridUpdates[@Manager],
                DCIO: colGridUpdates[@DCIO],
                Resource: colGridUpdates[@Resource]
            }
        )
    )
);
Select(Button6_1);
Notify(
    "Your hours have been saved!",
    NotificationType.Success,
    3000
);

However, I am getting the same result where the original data replaces the new, modified data.

[poweractivate]

@aakk9911 
Not sure your syntax is correct, it may be like this.

ForAll(
    colGridUpdates,
    Patch(
        ProjectTimeTrackerv2,
        LookUp(ProjectTimeTrackerv2, ID = ID),
        {
            StartDate: StartDate,
            EndDate: EndDate,
            TotalHours: TotalHours,
            NumberOfWeeks: NumberOfWeeks,
            HoursPerWeek: HoursPerWeek,
            Manager: Manager,
            DCIO: DCIO,
            Resource: Resource
        }
    )
);

However, it may be better to have a save button inside the Gallery and it patching just the one record as using a ForAll and a Patch inside of it is usually not a good idea in most cases, may degrade performance, and may not be the most optimal solution for most cases.

For this, try and see if you can add a Save button inside the Gallery and using just Patch on the one record. You'll know it's right when you see a Save button on each row of the Gallery.

Within the OnSelect property's formula you may use ThisItem to make it easier to get the current Item's values, including the ID, for your Patch.

You may use Patch(YourDataSource, {ID: ThisItem.ID, //...other fields to change for this record here}) and not even perform the LookUp to increase performance. Careful though - if the ID is missing, or wrong, in the two argument version of Patch, it may create a new record instead with some other ID.

Note that you may get a record scope error when debugging in real time in the formula bar. If this bothers you, test it first using a button outside, and use First(YourGallery) just to test with one record. Then when you see it working for the very first record, for the real formula on the real button, take all the "First" out and use ThisItem instead.

[aakk9911]

@poweractivate 

Thank you for your input.  I think in this case, there will not be many records associated with a project. My expectation is that there may be between 1 to 10 (max) gallery items associated with a single project with the average being around 3. 

With this in mind, performance isn't a priority in this particular use case. I've tried applying some of the ideas in the threads below but couldn't exactly fit it to my scenario so I'm hoping some of the bright minds here at PowerUsers can help guide me:

• https://powerusers.microsoft.com/t5/Building-Power-Apps/ForAll-and-Patch-Data-Not-Saving/td-p/408477
• https://powerusers.microsoft.com/t5/Building-Power-Apps/Changes-in-gallery-are-not-saved-SPO-list/m-...
• https://powerusers.microsoft.com/t5/Building-Power-Apps/Save-changes-button/td-p/1933198

[poweractivate · Accepted solution]

ForAll outside Patch is not recommended however if you are updating multiple records, and you want to avoid things like putting an individual save button inside the Gallery, then ForAll outside the Patch is sort of the only option when you really have to do what you're trying to do in that specific way. There's no way I know of to put a Patch outside ForAll when you must update multiple records to begin with, so this optimization isn't possible in this scenario. 

Since you don't have a lot of Records, and you won't even have 500 records at the project level, you  may be fine, though be aware that as your organization grows beyond expected, you may have to think about this in the future. 

For now, try this then:

ForAll(
    colGridUpdates,
    Patch(
        ProjectTimeTrackerv2,
        {
            ID: ID,
            StartDate: StartDate,
            EndDate: EndDate,
            TotalHours: TotalHours,
            NumberOfWeeks: NumberOfWeeks,
            HoursPerWeek: HoursPerWeek,
            Manager: Manager,
            DCIO: DCIO,
            Resource: Resource
        }
    )
);

 I've used 2 arguments instead of 3 (with the ID specified) for better results with Patch. This version is more concise and it also performs better, even if it's inside a ForAll.

If it complains, try using ThisRecord like below: 

ForAll(
    colGridUpdates,
    Patch(
        ProjectTimeTrackerv2,
        {
            ID: ThisRecord.ID,
            StartDate: ThisRecord.StartDate,
            EndDate: ThisRecord.EndDate,
            TotalHours: ThisRecord.TotalHours,
            NumberOfWeeks: ThisRecord.NumberOfWeeks,
            HoursPerWeek: ThisRecord.HoursPerWeek,
            Manager: ThisRecord.Manager,
            DCIO: ThisRecord.DCIO,
            Resource: ThisRecord.Resource
        }
    )
);

If you get any issues, there's something wrong with how you are using colGridUpdates.

You may temporarily try to use YourGallery.AllItems in place of colGridUpdates - but if that seems to work you need to fix your Collection.

Do not use YourGallery.AllItems as a Gallery loads the data in increments of some small number like 10 to 30 items at once, well below even the data row limit, so it's best to make sure you put them into a Collection, not use YourGallery.AllItems directly. You should avoid using YourGallery.AllItems to even simply count the records, instead use a Collection like you are doing for more reliable results, even when using something like CountRows. 

You are using ShowColumns and doing other things which may be causing your Collection to be incorrect, if you have issues you may want to double check how you are creating and populating that collection, specifically: colGridUpdates

When you use a Collection you can populate at once, up to the data row limit number of records in a single Collection.
That's 500, and it can be raised to a max of 2,000.
You can potentially have more Records than that in the Collection but it's not recommended to do this as this can cause some problems. From a single operation on the collection, the max is up to the data row limit number of records that can be populated in one operation, and I recommend you don't have more than around 2,000 records total actually held at once in memory, in total, from all collection records added together, for most scenarios.

Note that a data row limit does not care if the operation is delegable or not. Everything is subject to the data row limit, whether you see a yellow triangle or not.

Delegation only helps because you can bring the number of records from your source down to the data row limit or less while processing all of the records. This is usually when you use a Filter function. The more granular your Filter is, the better, as you may be able to leverage the strengths of Power Apps even if you have millions of records in your SP List or other data source. Make sure your Filter is the "innermost" formula. If you have other, nondelegable functions inside the Filter, that defeats the purpose of the Filter. This is not limited to Power Apps - limits like these are by nature of using a client, and in alternative clients you may not have the benefit of using low code, and you may have the same or even stricter limits, in addition to the lack of convenience of using Power Apps and a low code studio editor. 

See if it helps @aakk9911 

[aakk9911]

@poweractivate 

Thank you!!! It worked!  Even besides providing the solution, I want to thank you for also providing a detailed and thorough explanation.  It was a great learning experience.  Hope you have a great day 😁

[poweractivate]

@aakk9911 Glad to hear it! In case it helps, it may be possible to use a Patch for multiple records, without using ForAll, and this version might perform better.

Patch( DataSource, BaseRecordsTable, ChangeRecordTable1  )

However, it is a bit more complex to use this form of Patch than when using the ForAll.
You need a set of records, probably from a Filter. Each Record in BaseRecordsTable should contain the primary key of the record to be changed (ID for a SharePoint List), and the order of ChangeRecordTable1 must match the order of BaseRecordsTable exactly for the changes to work correctly. For instance, you might have the base records collection from a Filter, the exact same Filter used for a second collection to make it identical to the first (or, even just try to copy the base records collection into the other one with ClearCollect(ChangeRecordTable1,BaseRecordsTable) to avoid having to retrieve from the data source twice for the same thing), and all the changes are updated to the second collection somehow before you issue this form of Patch. 

It's far trickier to get this to work in your scenario than with your ForAll though. I would suggest keeping the ForAll for now. However, once you start having more than 300 records in one operation, or you start getting so many records you notice a slowdown, there is a way to avoid using ForAll in case it may help for future consideration in case this way helps to increase performance.

[aakk9911]

@poweractivate 

I've run into a slight hiccup, unfortunately.  The patch works well when modifying an existing record, however, when a new record is created in the gallery, the Resource name does not take.  For reference, the Resource name is a Combobox type field where a name can be searched in AD. If I attempt to patch to the Resource field with the new code, on Save, the name disappears from the box.

With my original code, the name did save in the Combobox.  With your provided code, all other changes are saved. I've tried combining with an If statement, like below to no avail -

Set(
    varResult,
    If(
        IsBlank(HrsGallery_1.Selected.ID),
        Patch(
            ProjectTimeTrackerv2,
            ShowColumns(
                colGridUpdates,
                "StartDate",
                "EndDate",
                "NumberOfWeeks",
                "TotalHours",
                "HoursPerWeek",
                "ProjectLookup",
                "Manager",
                "DCIO",
                "Resource",
                "ID"
            )
        ),
        ForAll(
            colGridUpdates,
            Patch(
                ProjectTimeTrackerv2,
                {
                    ID: ThisRecord.ID,
                    StartDate: ThisRecord.StartDate,
                    EndDate: ThisRecord.EndDate,
                    TotalHours: ThisRecord.TotalHours,
                    NumberOfWeeks: ThisRecord.NumberOfWeeks,
                    HoursPerWeek: ThisRecord.HoursPerWeek
                }
            )
        )
    )
);
Select(Button6_1);
Notify(
    "Your hours have been saved!",
    NotificationType.Success,
    3000
);

The idea here being if it's a new record, use my previous code, if changes/modifications are made, use your code. Not sure what's wrong here..