Form submissions override each other

Hi,

When a user submits a forms entry, sometimes s/he overrides the submission of another user.

User A submits the entry, it goes on row 11 of my table.
User B submits an entry, it goes on row 11 of the same table, overriding User’s A submission.

Any thoughts on why this may be happening?

Thank you,
Magdalena

How is your key column expression? Or might the table’s key column be the [_RowNumber]?

2 Likes

1 Like

Thank you @LeventK and @Steve. This was really helpful.

1 Like

You’re welcome

I started using a system generated key

CONCATENATE([Date],": ",[Email])

But I am still having cases where two users (two different emails) override each other.

I don’t need sequential keys. I need:

  • users to submit the form without overriding each other, even if they submit on the same day.
  • users able to edit their submissions (this is for bonus points).

Any guidance on the key question (pun intended)?

Thank you,
Maiga

@maiga
There is a possibility of the way appsheet is treating the format of your generated key in a wrong way because of the colon (:) in between the date and email columns. In general, the colon (:) - indeed it’s a double colon (::) though - as a reference directive. Your key generation seems allright and unique - as it contains the useremail - but try with changing it like:
CONCATENATE([Date],"-",[Email])

2 Likes

I will try this change @LeventK. Thank you for the very quick reply.

You’re welcome.

Please post a screenshot of the column list for the table from Data >> Columns in the app editor. Please ensure the screenshot includes both the key and label columns, at least.

Hi @Steve had to break it in 2 screenshots. The tough thing about this is that the user submissions are once a week and it is hard to test if the changes are working. Thank you for taking a look.

You key column, _ComputedKey, appears to be using the expression @LeventK suggested above:

CONCATENATE([Date],"-",[Email])

A problem with this key is that if a single user adds multiple rows in a single day, each additional row will overwrite the previous row, because each added row will have the same key column value. I doubt this behavior is what you want.

I notice you have a column named Uniqueid. I would encourage you to use this column as your key column by making the following changes:

  1. For the Uniqueid column, set the Initial value expression to UNIQUEID().

  2. For the Uniqueid column, set the Editable? expression to FALSE.

  3. For the Uniqueid column, optionally set Show? to OFF.

  4. Delete the _ComputedKey virtual column altogether.

  5. For the Uniqueid column, set Key to ON.

2 Likes

This is very useful @Steve.

I had not understood from any of the documentation that "initial value’ needed to have the unique formula, I had tried it before and kept getting errors. Thank you for explaining.

When I use uniqueid() users are not able to see their past entries.

I think i’ve solved for the problem of multiple entries by same user by switching from a form view to a table view. The user will be able to edit their entry. I’ll see if this works and if it doesn’t I’ll try your solution.

Thank you again for your help.

Maiga

You really need to read and understand the What is a Key? document I posted above. If you don’t understand keys, you will find AppSheet extremely frustrating and confusing.

3 Likes

I see. I thought that I had understood the concept but I’m missing something. I understand that the key is unique but the other row content can change without messing the key, correct?

Context:

My users do a weekly entry, every Monday. The row is identified with the key

CONCATENATE([Date],"-",[Email])

Users should have 1 entry per week. I want them to be able to go back and edit their weekly entry if necessary (e.g. Wednesday they need to do some changes). Then, the following week, they have a new entry.

Where is the obvious gap in my understanding? Any orientation is much appreciated!

Thanks,
Maiga

Correct.

It appears it is what you want, so @LeventK’s suggestion is a valid one, and my suggestion to use UNIQUEID() is unneeded.

1 Like