Sequential ID by sensing the source table?

[Marco_C4s_tro]

Good morning everyone, I am trying to create a sequential ID auto-generated by 2 form fields and a field that is the row, the problem I have is that it does not reserve the space of that row when two users with the same access enter data simultaneously.
I don't know if it is because there is no constant feedback from the google sheets table, but when one of the two users enters the data first, there is a clash with the ID, since the row to which both accessed, is the immediate previous one, but not the one that is updated.

Example: 

CONCATENATE
(
UPPER(LEFT([Descripcion], 4)),".",SELECT(Categorias[SN], [Category] = [Clasificacion]),".",SELECT(Sub Categorias[SN], [Sub Categoria] = [Categoria]),".",[_RowNumber]-1
)

What I need to know is if there is a way to automatically reserve or change the last value of the empty row, so that there is constant communication and there is no ID error when you want to replicate or use the same row? 

I hope I have made myself understood what I am asking. Good day to all.

[WillowMobileSys · Accepted solution]

---

@Marco_C4s_tro wrote:

What I need to know is if there is a way to automatically reserve or change the last value of the empty row, so that there is constant communication and there is no ID error when you want to replicate or use the same row? 

---

The short answer is no.  

The reason is because this is a distributed system - each device operates in its own "sandbox" - i.e. each device has its own copy of the app and COMPLETE data on which the user interacts with.  Changes are then submitted to the server for entry into the shared data store.  When more than one user makes an update to the same row, the last update wins!

AppSheet operates as a distributed system to support offline access.  If a device loses connectivity and the app is so configured, a user can still operate on the FULL app with no issues.  Changes are retained on the disconnected device.  Once connectivity is restored, all saved changes are submitted.

The nature of a distributed system will not support row locking efforts nor will it support sequential numbering across more than one user. 

However,  understanding that this is a distributed system, with some business process adjustments you should be able to avoid any problems with conflicting data updates and likely don't need to rely on sequential numbering.

[Marco_C4s_tro]

That's what I thought, the only solution that comes to my mind, is to present a sequential ID and have a relational ID between tables that is automatically generated by appsheet. Thank you for your respond, it was really helpfull.