Auto Increment

[Matthew_Saragusa]

I think I’ve read all the threads on this, but I don’t have an answer.

Is there a sequential auto increment, or at least a number generator. For instance for a human readable “order number”

It wouldn’t matter if the number is actually sequential, but it needs to be human readable and unique no matter what. Every time someone adds a record with a form, it needs to have a unique number. I’ve used max number in glide, but sometimes if there are two users trying to do add an order at the same time, they will duplicate. I’ve tried google sheets array formula, but if someone deletes a row, that changes everything with old data.

Is there a way to get a unique number every time one is requested? I’ve even thought about making a sequential number with an external api, that no matter what, when the api is called, it will create the next number, pass it back and save it to the order number column.

[Eric_Penn]

Have you tried the Unique Value ID?

Unique Identifier | Glide Docs

If you absolutely need a number I would follow @Darren_Murphy guide.

How do I create an auto-incrementing row number with Glide Tables?

This is a question that comes up a lot, so creating this topic to use as a reference. Typically, there are two distinct use cases when it comes to auto-incrementing row numbers. Use Case 1: – We need to generate a Part Number, or an Order Number, or an Employee ID. Once the number is generated, it should never change, even if rows are deleted. – The general approach for this use case is to maintain a static counter, use it to craft a suitably formatted ID, and increment it by one every time…

I hope this helps!

[Darren_Murphy]

The method shown in my tutorial is also subject to concurrency/race conditions, so is probably not suitable in this case.

@Matthew_Saragusa the only way to be 100% certain of avoiding collisions is to delegate the allocation of your order numbers to an external 3rd party. The problem with doing this in Glide is that all calculations happen client side, so it’s always possible for 2 or more clients to come up with the same number independent of each other.

Your API idea should work - as long as the API is maintaining an independent counter. If it’s using anything that comes from the client to generate the number, then you have the same problem.

What I would do in this case is use Make (Integromat). When a new order is created, trigger a webhook from Glide with just the generated RowID as a parameter. Make would then pop the next available order number from the stack (which could be just a simple increment), and then set the order number to the correct RowID via the Glide API. There would be a slight delay with this method before the order number appears, but no more than about 5 seconds.

[Matthew_Saragusa]

@Darren_Murphy yes, that’s what I was afraid of, Glide doing everything client side.

Based off your note above, this is what I understand.

• Glide makes a new row, calls a webhook with Make, passing the RowID.
• Make generates an increment.
• Make does a lookup on the row with the RowID that was passed from Glide.
• Make populates the row’s order number with the auto-incremented number.

WOW! This sounds nuts just to get a sequential number. Autoincrement is such an important feature of many programs. With all the things that Glide can do, why would they not implement this?

[Darren_Murphy]

@Matthew_Saragusa

• Glide makes a new row, calls a webhook with Make, passing the RowID.
• Make generates an increment.
• Make does a lookup on the row with the RowID that was passed from Glide.
• Make populates the row’s order number with the auto-incremented number.

That’s more or less it, although steps 3 & 4 would be a single step. That is, you don’t do a lookup, you just do a direct Set Column Values call passing the RowID as a parameter.

@Matthew_Saragusa

Autoincrement is such an important feature of many programs. With all the things that Glide can do, why would they not implement this?

I can’t speak for Glide Engineering, but I could imagine this would be quite a challenge given the current architecture. What I do know is that Glide is currently beta testing an alternative server-side computational model (I know, because I’m part of the beta test group). If/when this becomes a reality, then things like this I suspect will be a lot simpler to implement.