SAVE button - Action

jaichith · 07-06-2024 07:26 AM

Hi ,

Is it possible to check a condition or run a action before saving the form and followed by action after saving ?

or

Is it possible join an action along with form save event ? this should happen first and there after saving ?

I need the above functionalities for this post - How to avoid repeating/duplicates when multiple users use the app

Implementing the Locking Mechanism:

Step 1: Create the LockTable

CREATE TABLE LockTable ( Locked BOOLEAN DEFAULT FALSE );
Step 2: Create an action to lock the table before saving
appsheet

UPDATE LockTable SET Locked = TRUE WHERE Locked = FALSE;
Step 3: Create a conditional workflow that checks the Locked status before allowing the save
appsheet

IF( SELECT(LockTable[Locked], [Locked] = TRUE), WAIT, MAX(TEST[SL NO]) + 1 );

WillowMobileSys

Because AppSheet is a distributed system, there is nothing you can do to prevent duplicates when entered by different users at approximately the same time. Each user operates independently from all other users with their very own app AND data copies.

The best you can do is minimize duplicates based on data already entered. Then handle duplicates from simultaneous entries in one of two ways:

1) Process changes in the way users use the apps. Why do duplicates happen? If you think about it, that fact that two users are already entering the same data indicates an inefficiency in the business operations. It's duplicated efforts across users/employees that should not be happening in a well organized operation. Changing the business process, so duplicated efforts don't happen in the first place, is the best course of action - for the organization all around!

2) If it's a case where duplicated efforts can't be prevented, then there is no choice but to react to the duplicate entries only after they occur. One entry will always occur first, when the second entry is applied and detected as duplicate, then you will need to include steps in the process to resolve. For example, maybe those steps are to DELETE the second entry and possibly send a notification to the second user that the entry failed due to duplication and maybe include a link to the successful row so they have a chance to update the record with details they know that the first user didn't. I believe you can handle this with AppSheet automation but if not for some reason then definitely an AppScript or integration service can do the job.

I hope this helps!

jaichith

@WillowMobileSys wrote:
1) Process changes in the way users use the apps. Why do duplicates happen? If you think about it, that fact that two users are already entering the same data indicates an inefficiency in the business operations. It's duplicated efforts across users/employees that should not be happening in a well organized operation. Changing the business process, so duplicated efforts don't happen in the first place, is the best course of action - for the organization all around!

2) If it's a case where duplicated efforts can't be prevented, then there is no choice but to react to the duplicate entries only after they occur. One entry will always occur first, when the second entry is applied and detected as duplicate, then you will need to include steps in the process to resolve. For example, maybe those steps are to DELETE the second entry and possibly send a notification to the second user that the entry failed due to duplication and maybe include a link to the successful row so they have a chance to update the record with details they know that the first user didn't. I believe you can handle t

brother,

here duplicates which mean here is Serial numbers, same or duplicate serial numbers are produced by the app during record creation . Serial numbers are created by using the initial value expression MAX (TEST[SL NO])+1 .

@WillowMobileSys wrote:
update the record with details they know that the first user didn't. I believe you can handle this with AppSheet automation but if not for some reason then definitely an AppScript or integration service can do the job.

to the maximum, I avoid external scripts since whenever we make copies of the app. it will create more work load to the app developer in general. because scripts and internal setting everything has to be changed for every copies.

if you can help me with this post it would be better me to achieve what I want.

Thank you.

TeeSee1

I did further testing.

A bot triggered on a row added event which populates the col with MAX(table[col]) + 1 via data action seems to work. I can create only simple concurrency conditions (two app instances on one PC, another instance on a smartphone, both online and offline) but no duplicate numbers are generated.

As you are perfectly aware the whole issue of generating unique sequential numbers has been discussed numerous times. Maybe you or someone else have already tried it and found it unworkable. If not, give it a try and see if it works.

jaichith

Dear @TeeSee1 ,

I sincerely thank you for testing based on my requirement.

@TeeSee1 wrote:
A bot triggered on a row added event which populates the col with MAX(table[col]) + 1 via data action seems to work. I can create only simple concurrency conditions (two app instances on one PC, another instance on a smartphone, both online and offline) but no duplicate numbers are generated.

same kind of setup I have tested , somehow it works as per my need but reliability is a question mark here. because MAX() +1 may act concurrently in bot too , I have found by testing through a automation. (bot is pending for time even after conditions are met). Incase if it true, we are in situation to find workaround for concurrency in bots.

some of relatives who are into IT field has suggested queued and lock mechanism for sequential numbering lets how it works...

I request you to help me in this question -

Post for your notice

TeeSee1

Well I used my four fingers and 'successfully' produced duplicates.

So the bot solution does not work. As for implementing a more sophisticated mechanism like you are saying, I don't think it is doable within AppSheet.

I believe Apps Script is the way to go like scott192 proposes. Again, without understanding how Apps Script executes requests from AppSheet, there is no theoretically assurance that it is fail safe but at least I could not produce duplicates (I admit, it is difficult to test...)

So as far as I am concerned, I see the following paths you can evaluate...

1. Use a platform that supports this functionality

2. Go with an Apps Script solution after you test it to your heart's content. (If there is a quiet period like really late at night, then you can schedule a bot to assign numbers without issues)

3. Give up on the sequential number concept. Unless it is a legal requirement and you need to use AppSheet for some reason, then it should be acceptable.

Well, good luck.

TeeSee1

Just to give additional info to anyone interested in the community, I ran more concurrency tests using an Apps Script solution and the result was that it FAILED.

Here is what I did. In order to load the system(s) I create an action to add a row to the target table using data from this row. The source table (which actually has no business logical relations with the target table under test) has ten rows meaning I can send ten row creation actions evoking ten bot triggers using the bulk action method 'simultaneously'. I launched four instances of the App and did the same on all of them more or less simultaneously. Out of expected 40 rows and 40 sequential numbers, I got one duplicate number (39 unique numbers).

Again I do not know what caused the duplicate but the result, which is what counts, was that it does not 'reliably' create unique numbers.

It is what it is..

WillowMobileSys

@jaichith wrote:

if you can help me with this post it would be better me to achieve what I want.

"...You can't always get what you want..."

You are trying to maintain sequential numbering amongst simultaneous users which is an even bigger problem. Technically, and because of your constraint to operate within AppSheet's system, it is not possible to altogether prevent duplicate sequential numbers, again, because this is a distributed system.

The BEST you can do is minimize the occurrences and then react to the duplicates when they do occur. They will occur and as more concurrent users utilize the system the frequency will increase.

I would strongly encourage you to eliminate the idea of sequential numbering. I NEVER use them as they provide no real value. I know, I know - your client insists. But there are other, and better ways, to achieve the value they think they are gaining.

I'm sorry...but those are the facts. Accept them or not.

I hope this helps!