Hi all,
I’m building a custom form with the purpose of updating client information. While not very likely, I’d want to prevent two (or more) users from updating the same client at once. In other words, prevent them from being able to update the same client on the same time. I’ve read many of the discussions here about how to avoid duplicates but didn’t find an answer to my question: can a non-USC column help here?
In detail: the idea is to add a non-USC column to the clients table. Something like “currently being edited” as Boolean. Once anyone starts to update a client, this will turn into “True”. This, in turn, will disable the option to start another update form for the same client. In the beginning, I was thinking about having this column inside the temporary working table which is associated to that form. Only later on have I thought that it’s probably better to have this column in the “bigger picture” table , the client list.
Once form is submitted, Boolean will be turn back to false. This means that in theory the same client can be edited a second later but the update form will already show the up-to-date details, as edited just a second earlier.
Hope I explained myself correctly. Let me know if not.
Thanks
You have the right idea here, but that does not prevent a case that user A starts the editing process of a profile, the boolean is set but it does not sync in time for a user B that wants to edit the same profile. The result is likely that user B will enter the edit screen as well.
Agree with what Thinh said, and also this approach would do nothing in terms of preventing duplicate entries.
Perhaps duplicate prevention isn’t the right phrase to describe this. Thanks for your valued input.
If we’re on the subject, I’d like to ask a general question:
What is the best practice for using non-USC column in temporary tables designed to support custom forms? These tables are normally a single row table. I’m a bit confused about how the system “sees” this single row differently for each user, especially in light of a non-USC column in the mix.
I’m not sure that there is an accepted best practice, but there are a few of us that use (and promote) the working table approach. It’s generally a cleaner approach and keeps the extra columns out of your main tables.
In terms of user specific columns vs basic columns, they behave as you would expect. That is, the values in user specific columns will be unique for each user, and the values in basic columns will not be.
When I use basic columns in a working table, they will almost always be read-only - in terms that I won’t allow them to be changed. They’ll usually be used for reference. For example, I might have a column with a list of values that get used in a choice component. Another example is that I have have a table with 12 rows - one row for each month of the year - and I use these to build relations to tables elsewhere for the purpose of summarising data by months. Another example that I’ve used quite a bit lately is where I need to “transpose” a series of columns into a single column to use in an inline list or choice component.
So it depends. Working tables have lots of uses.
Thanks.
Follow up question: what would be your thoughts about using the table on a non-temp basis?
Continuing with my previous example in this post, let’s assume the form is supporting the process of updating client details. The reason I use a custom form, and not “edit”, is the fact there’s no data validation possible within Glide forms, including “edit” forms. If the table will not be temporary, I’ll get another use for it as a change-log for all clients. What do you think? Is it better to have this log in another, dedicated, table that’ll get its data from this form?
Are you suggesting that you’d write a new row to this table each time and leave it there?
I think that could get quite messy, so I don’t think I’d do it. I’d recommend using a separate table as a change log.
That’s true, it’ll get messy.
Last question, I hope:
In this temp table I currently have all columns that receives the updates as basic (non-USC). I know that the best practice is to have them USC but I’d like to get a better understanding of the logic behind it. Could you explain the downsides of a non-USC columns in this case?
I’d clear all values once form is saved or canceled.
The downside is that you can only allow one user in the form at a time. I know you started this thread by suggesting that you’d try and implement a locking mechanism to enforce that, but as @ThinhDinh pointed out, that isn’t guaranteed to work. And so by using non-user specific columns, you’d risk a situation where you could have two or more users in the form at the same time, clobbering each others data.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.