Hi,
I had the same dilemma in the past. I was using Dropbox and it inevitably resulted in multiple records with non-unique primary keys.
Here are some things I had tried:
- I placed my students in rotating small groups so that there would be fewer at the station using the apps at the same time to try to avoid saving over one another, but it didn't work out.
- I tried identifying the maximum record prior to getting to the spot when filling out the form, but two users identified the same id yet saved at different times.
- I wrote all the other fields, then went back to update just the id number, but this required two writes. It mostly worked, but this was 20s per Patch at the time since I was using Dropbox. It fell apart when I hit 500 records since Max() is an aggregate function that isn't able to delegate yet.
- I switched to Common Data Service, which worked out since it was automatic and guaranteed to produce unique values.
Google Sheets is pretty fast at writing, but do be warned if you access the datasource too much, you may hit one of their quotas--either by volume or frequency. So if you want to proceed, the following might work out with minimal chance of error, but the chance is still there. The following solution will work if you do not expect more than 500 records in your datasource.
The idea is that you will Patch the record as usual (red), but keep the field for your primary key blank. You will collect the result of the patching to a variable (blue). Then you will use the variable to identify the record in the datasource you want to edit again so that you can apply a primary key after the fact (green). You can refresh before you calculate that primary key to have more certainty.
So your formula might end up looking like this:
Set(temprecord,
Patch(datasource,Defaults(datasource),
{field1: data,
field2: data
}
)
);
Refresh(datasource);
Patch(datasource,temprecord,
{primarykey: Max(datasource,primarykey)+1
}
)Let me know how this works out for you.
Microsoft Employee
@8bitclassroom
