Adding a new row to another table action

Thank you

I got it to work by removing the Valid If expressions for the Category and Sub Category columns. Progress! More to come…

2 Likes

Just as an aside: whenever I encounter situations like this, where I’m needing to continue forward with developing and the general functioning of the app but I can’t due to some bug or something weird, I’ll find a way to “brute-force” something to work.

One of the advantages of the AppSheet platform is it’s flexibility. :wink:

What I’ve done in the past is to create an additional column in the table to store a temporary variable which I use to indicate when certain actions should run, certain validations should be enforced, etc.

I call the column “Form_Type” (but it can be called anything) and I use a series of actions to set and clear the field based on what I need when.

What I was thinking is if you did this, you could set your required formulas to not be required all the time, but only required when a certain variable is in the Form_Type field.

This way when you create your record in the background, you could exclude this variable from being added - thus causing the required formulas to ignore things.

1 Like

I have reproduced the problem to a trivial case. It appears to be, as @MultiTech_Visions hypothesized, due to dependent drop-downs. I’ve escalated the issue internally.

In my trivial case, I created an app with two tables (Table 1 and Table 2) each with two columns (A and B). The columns of the second table have Valid If expressions referencing the corresponding column of the first table (e.g., Table 2 column A used Table 1[A]). By merit of being adjacent columns referencing adjacent columns, a dependent drop-down relationship is created. I then created an action to add a row in Table 2 from the values of columns A and B of a row in Table 1. Confirming the hypothesis, the action failed. Somewhat surprisingly, if the columns set are listed as B then A, the action succeeds.

More to come…

1 Like

Thank you for the update @Steve

1 Like

Hi @Steve. Were you able to glean anything else from this issue? Just to test (in the hope of being able to proceed :smile:) I built the Valid If formulas in the form manually as @MultiTech_Visions referred to previously but am still being presented with the same error when trying to run the action. This may have been expected, I don’t know.

No further progress over the Labor Day holiday here in the US yesterday. I do think this is a bug and will have to be addressed by the developers. Like I said previously, I have escalated it internally. In the meantime, the best we can hope for you is a work-around. In my testing, the ordering of the columns in the action can affect the behavior: specifically, ordering the dependent columns before the columns they depend on. Try tinkering with the order of the columns in the action.

1 Like

Great thanks @Steve

Hi @Steve. Not sure if it will help with the analysis of this issue but I created a Scheduled Report and added in the ‘Automate Open Ticket’ Action, ran a Test and the system recorded an error in the logs. If you think it may help to review the error you are still a Co-Author on the app. The Report I ran a test for is ‘SM for Maintenance - Every 1 Month’.

I’m not sure if I’m experiencing precisely the same issue, however, when I’ve experienced the error “Could not set value because column X would become blank and required”, I’ve worked around it by adding a context formula to the REQUIRE? flag. Usually I add something simple like CONTEXT(“View”)=TableName_Form

That way when I am actually entering data in a form view the field is required, but when the action executes it doesn’t recognize the field as being required. Note that I have a different form view for the one that executes my action vs the one that actually edits a row.