@Bamr I don’t know if you would want a button just to decrement an inventory item. You could simply create a relation column to link to your purchased items, a rollup column to count the number of purchased items, and a math column to subtract that rollup value from a starting inventory.
2 Likes
Thanks for the feedback. Rob’s work around is clever and would work but would be overkill for such a simple calculation.
I actually found another App service calls AppSheet that has exactly what I was looking for, and a bunch more.
I think we have the winner now!!!
The new action called Increment within Action Text´s features makes this posible!
I´m watching you Glide!! 
Saludos
Yep…you can use this as a (mathmatical) reset button as well!
1 Like
I could use this for a score card I have for my classroom. Each time they mine an asteroid they earn 500XP.
Hi
I’ve asked around on another topic on this issue. Does anyone have an idea if this, or any other similar action, is protected from concurrency/race condition?
In other words, what happens if two users trigger the increment action on the same time?
Thanks
No, it doesn’t.
I’ll respond to your other post shortly (I’m away from my computer at the moment).
Hi @Robert_Petitto and @Darren_Murphy,
One of the reasons for using this numeric value was to in order to have a truly 1:1 relationship between tables. This should survive any changes done by the users, including changes I didn’t think about and they somehow find a way to do 
I had an idea which I’d like to run by you:
Assuming we are using a temp working table, how about we take the RowID of that temp line and set it on the relevant table which we’d like to create this 1:1 link?
In order for Glide to regenerate a RowID for each new submission, the submit action will delete that temp row and then add a new row to the same temp table. We delete because just clearing the values won’t regenerate the RowID, it’ll use the same RowID for each user. We have to add a row because without it the user cannot enter the custom form.
Yes Darren, I’m playing around with a copy of your wonderful Custom Forms app
(there’s no real logic with have the 1:1 connection between Animals and Users. It’s just for testing).
Some other questions:
- What is the purpose of “unique identifier” and how is it different from RowID? It’s generating a different unique value for each table in which we set values, so it cannot be used as this 1:1 link.
- How does the reset button come into play here?
Thanks
Nice question
I think…
This is the answer you are looking for here. I’ll use my custom forms app as an example. Let’s say we wanted to allow users to add an arbitrary number of images for each animal. How would we handle that? A naive approach would be to add a bunch of extra image columns to the Animals table. But that’s not going to scale - what happens if somebody decides to add 500 pics of their pet cat? Do we have 500 image columns to cater for that possibility? Of course not. We move the Animal pics to a separate table. But we need to be able to link each image to the correct animal, and this is where the Unique Identifier comes in handy. If I was to add that functionality to the demo app, this is how I would approach it:
- I’d start by creating a new table to hold the images, with columns for the Image and an AnimalID
- I’d add an extra AnimalID column to the Animals table
- I’d add another User Specific text column (
usc/animal_id) to the Working table - When a user opens the form to create a new animal, the associated action would do a Set Column Values on that column, using the Unique Identifier special value
- Creating a new animal would become a multi-step process. In the first step, they’d just provide the animal name and save. This would add a new row to the animals table, setting the AnimalID to the value of that user specific column.
- I’d keep the user on the same “form” screen, and then give them an option to add images. One at a time, as many as they like. Each time they save an image, a new row would be added to the Animal Images table, using the same AnimalID value.
This is a bit clunky, and I wouldn’t recommend this. And I’m not even sure how well it would work. I think you’d be much better off leveraging the Unique Identifier.
Which reset button?
1 Like
This reset button
This is the main challenge with using this unique identifier. A multi=step process means more chances of increasing the abandonment rate in mid process. My goal is always to ask as little as possible from the users, by trying to do as much of the work as possible behind the scenes and with zero involvement from the user. As you can see in the screen shot I sent earlier, the idea is to write to both table with one action. In your example, that would be to write to both the animals table and the image table, all in one swift move. For this, we need the link. Enter RowID As it’s coming from the worktable, we can use it as a connection between two (or more) table to which we write during the same action. It’s too bad we cannot setup the unique identifier as either a column in the working table (with an option to reset after each submission), or simply configure it to repeat itself with an identical identifier for multiple tables.
Where do you see the problem here? Is it the delete row followed by the add row? Do you know of another method to regenerate the RowID in the working table?
Thanks
oh, right. Not sure how that applies at all in this context.
You could still do that using the Unique Identifier method. The example I gave was to cater for the case where you don’t know in advance how many “child” records the user will be adding once the parent has been created. If in your case it’s just one of each, you can just as easily collect all data and add rows to both tables using a single step.
Yes, but also the fact that’s it’s a really round about way to approach the problem. This is exactly the type of use case the Unique Identifier is suited to, so why not use it? It’s a bit like you have a star screw that you want removed, and I hand you a star screwdriver, and you say “No, thanks - I want to use this flat head screwdriver. Can you tell me how to make it work with a star screw?”
Sorry, I missed this part of your earlier reply.
But you can do that, and it’s exactly what I’m suggesting. You add a user specific column to your working table, and set that with a new unique identifier value when a user opens the form screen. Then when the user submits, you use that value in your Add Row action/s. Because it’s user specific, it will be a different value for each user, and for each new instance of the form.
And this, by the way, is where your RowID idea will fall down. Because the RowID is not user specific, it will be the same value for every user. And so if you have two or more users in the form at the same time… I’m sure you can connect the dots
And what will happen if the row is deleted by one user, while 3 other users are in the form at the same time? oops…
1 Like
This 
1 Like
Ahhh…I didn’t know that…
Naturally, changes everything and, as you said, kills my idea 
My bad, I understood earlier that we pass this UniID only upon submit. Not very smart of me…
Forgive me for asking every detail, but I’m still learning the ropes here.
When we open a new screen we set the data to the relevant working table.
However, when coming to set UniID value for “this item” , it shows the columns from the table we came from.
In your example, it’s “Animals”.
I see you added a relation column. Is that specifically for solving this “jump” between tables?
Yep!
And does it matter what the relation fields should be?
In other words, do we even care if such a relation is indeed found, or if it can even be found?
Even more words, can we link between name and phone number, for example? a never-happening relation
Yes, it matters. If the relation is empty, it can’t be used for this purpose. You’ll notice that I used the ID of the currently signed in user. This is a common technique for building single relations for this purpose. It’s a sound approach, as it’s guaranteed to always work. By work, I mean the relation will always be formed.