Users are adding new rows with the same key

[Swoopy]

Is it possible that AppSheet mistakenly saves 2 rows or more with the same key coming simultaneously?

[pravse]

No. The first row would be added. When another user tries to send the same row key in a row, it will be treated like an update to the original row.

Usually, you avoid this sort of thing by having keys with unique values. The UNIQUEID() function is very useful for generating such keys without conflicts.

[Swoopy]

I tried saving from 2 devices with the same data having the same row key at the same time. Both were queued for sync and then both of them were saved successfully without warning on any device.

I watched what was going on on spreadsheet file. AppSheet saved the first sync from one device and then followed by the data from 2nd device (they contain different message in other column so I can see the whole process).

At the end, the spreadsheet file has only one row of this key with value from the last device that successfully saved.

[pravse]

Yes, that’s right. Because when the second device syncs the row, the system treats it as an update of the row (it checks to see if the row is in the sheet based on its key, it is, so the system says — ok, this must be an update not an add).

[MultiTech]

praveen:

(it checks to see if the row is in the sheet based on its key, it is, so the system says — 🤷ok, this must be an update not an add).

Now if we could only get this behavior for the background record creation action - then we could use that to update previously existing rows in the same manor.

[Steve]

MultiTech_Visions:

Now if we could only get this behavior for the background record creation action - then we could use that to update previously existing rows in the same manor.

Works for me. Well, with caveats.

[MultiTech]

Steve:

Works for me. Well, with caveats.

Wow. It’s only been a few weeks since I tried that and it didn’t work.

@Steve What at caveats do you speak of?

[Steve]

MultiTech_Visions:

What at caveats do you speak of?

As I recall, last I played with it, the new row with the duplicate key would occur in the app along with the original row until the app synced, at which point the original row would disappear. So for that span of time, there would exist two rows with the same key. To work around, had to use a slice that only allows the row with the highest row number for a given key. Ugly, but it “works”.

[Swoopy]

I further played with inventory logic. Normally a product is issued out many times until balance is 0 then the app does not allow more issuing.

I have valid expression to check the balance before allow user to save data. If the saving quantity makes minus to the balance then there is message shown like ‘Over requested’.

The problem is that if 2 or more users trying to request 1 piece of the same product that remains only 1 piece in stock, their requests are saved successfully because of the delay sync. This makes balance the minus value.

My work-around is making a workflow to check balance after data saved and delete it if balance is minus. This workflow quite handy but sometimes it deletes every saved rows of those users instead of keeping at least 1 row that not making minus balance. And sadly I don’t know how to warn the users when their data have not saved. (I could send emails to them but it’s not practical.)

[MultiTech]

@Swoopy

Instead of deleting the duplicated row; I would make a system that flags that duplicate and alerts the user that submitted it.

That way the data the user submitted isn’t gone, they just need to go back and change the item the selected, etc.

If your users are using a device, then you can make use of the notification system native to AppSheet.

If your users are using a PC, then you can integrate notifications from https://pushpad.xyz/

[Swoopy · Accepted solution]

Thanks.