I am using the integration API Call in a column. It to generate unique IDs to avoid duplicates.
Each time it is called it gives you the current number and increases by 1 (atomic operation)
I am calling the API in a column and I get the following
The one in red 2000008 is my unique JOBID, however, I am not able to access this in the builder/UI, when I try to set a number component to the APIColumn it remains blank.
Also when setting it up I saw that I can refresh the API at a time interval, is it possible to call the API every time someone opens a FORM that relies on that APICall ?
I guess my other option is to do it as an action, but then I will be consuming extra edits (call API, write to row). I expect to came about 40,000 calls per month (not a cheap way to get a unique integer, need to try to explain to the client why a number generator is so expensive )
I strongly recommend using the Row ID column for unique IDs.
This approach here will likely not work. Here Glide is deduplicating the calls to the service and sharing a cached result. You can differentiate the calls be adding the Job ID (for example) as a parameter to the API call.
Not sure what you mean here, this is what I was doing but I cannot guarantee that the number will be unique, that is my problem, everything I try results in duplicates at some point.
This is due to race conditions. I open a form pull in the NEXT unique number but I cannot update it until I do not submit, and in the meantime someone else opens the form they will pull in the same unique number.
Not sure if I have misunderstood what you are suggesting.
Yes, I was doing the first method, but in a slightly different way, the issue is that if two applications (either 2 users, or the same user decides to open the form on his phone and laptop) open the form, they will get the same unique ID, as it is not incremented until you don’t save.
The issue with the second/dynamic logic is that it works as long as you do not want to have the unique numbers fixed (i.e dynamic) but for invoices I can’t change the invoice number once given and in that case it will result in a duplicate.
Just had a thought, maybe have a unique counter using the MAX, MAX+1 but do not use is as the unique number but as prefix. Then take your create time stamp and get the sec+ millisecs and add it to the end of the prefix. This should drastically reduce the probability of a dublicate
To prevent what you call the race condition, I think you would have to use Make/Zapier for this, but then you would also have to query the table to see the “latest record”, which requires Business/Enterprise.
My thinking is:
Submit the record as usual through the webhook.
Query the tables to see the ID of the last record.
Increment that ID (number) by 1, and then pass it to the next record.
Since the webhook payloads are queued, that might help.
Hi Dan! I have a feeling that you may find this Live build recording (from Loqode school) interesting.
In this Live Build Marco shows how to build custom search bar, create index numbers for items and generate unique incrementing numbers that won’t recalculate after deleting a row, and much more!
𝗖𝗼𝗻𝘁𝗲𝗻𝘁𝘀
00:00 Delivery/Inventory app.
03:27 Search component value not clearing.
07:47 Creating custom search.
18:33 How to set up completion check for multiple item process.
30:43 Generating unique sequential (incremental) order number.
1:03:53 Document Masterclass recap.
hey @Nataliya_Kovaleva - unfortunately the techniques that Marco was using will not solve the problem here. Order numbers are still calculated on each users device, so if two or more users add an order at the same time, they will all get the same order number.
@Dan_San - what about making the IDs unique per user? That is, include some user identifier in the ID (the users initials?), and maintain a separate counter for each user in the user profile row.
You could also maintain the counter in a Data Store, and avoid the extra API call.
I am actually using a different counter for each user in the profile and increment it. This drastically decreased my duplicates but I still get 1 every 2 days, I think it is because they are either using multiple devices or they are sharing their credentials.
The solution that Marco suggested, I think, will work. The problem I am having is that I am reading in the nextID at the time of opening the form and that form can be opened for 10mins and that gives 10mins for another form to be opened and pull in the same ID. However Marco is pulling in the ID at submit, incrementing it and then saving it to the row. Technically for you to get a duplicate two different persons will have to hit the submit at exactly the same time (extremely low probability). It does mean that I can not show the ID until they don’t hit submit, not nice, but I can live with that.
This is the best solution so far, and I can’t see a better one, without Glide developing a specific feature for a uniqueID incrementor.
hmm, maybe I didn’t watch enough of the video. I watched about 20 mins of it starting at the 30min mark. So my previous comment was based on what I saw up to that point.
Personally, I would use Make + Data Store. I’ve never actually had to do it, but I don’t see any reason why it wouldn’t work and be 100% reliable. When I have some time, I’ll put together a POC to test that theory.
)
𝗖𝗼𝗻𝘁𝗲𝗻𝘁𝘀