Why Doesn't This Formula Work?

[cnr]

Formula is:

WithName(
  AddRow([Table 1]),
  newrow,
  [lookup table 2]
    .ModifyRows(
      [Table 2].[Table 1 Inputs],
      If(
        [lookup table 2].[Table 1 Inputs].IsBlank(),
        newrow,
        [lookup table 2].[Table 1 Inputs].ListCombine(newrow)
      )
    )
)

It may be related to

withName row variables cannot access column values in certain cases

Not sure if this is a bug, but it seems that named variables (via withName), at least in some cases, cannot have members referenced. For example given a table “Some Table” that has a Name column: withName([Some Table].First(), first_row, first_row.Name) …fails at runtime as Name column cannot be found on the row, for some reason. Thank you! [UPDATE] View below thread and coda doc bug example with RunActions.

and WithName() bugs

@Jason_Tamulonis, is this expected behavior?

[Federico_Stefanato]

Hi @cnr ,
Interesting case, but I’m not sure I completely understood it.
What is your purpose?

You say:

I’m trying to add a new row to [Table 1] and then to add that row to the column Table 1 Inputs in [Table 2]

However, AddRow() formula returns an Action, not a row (*).

Therefore I expect that the quirky behaviour is due to the fact that the first time it adds the full row by guessing the data inference taking the origin of this action.

Let’s say that I’d expect an error, in this case, as we are comparing Action and Row (Ref) objects, but
I’d not consider it a bug (more on this from @Jason_Tamulonis and other @codans, I hope)

Also, I think it’s not related with the WithName() bug (now fixed): that was a due to a referential context not passed to RunActions() within WithName().

Edit.
In the document I provided an example of how to refer to a newly created row.
I’m sure @Paul_Danyliuk (guess who… ) fully explained about it but I cannot find the original post.
It is a typical use-case of opening the detail of a newly created row in a different table.
It still relies however on the “forced” way to create a row from an action, though.

(*)
As said sometimes in the past, I would open this topic.
I think that returning the subject of the action - rather than the actions itself - would be more useful and intuitive, as you pointed out with this post.
So add/modify/delete row should return the affected row(s) by simplifying significantly the logic of some typical use-cases.
Happy to discuss more about it.

[Jason_Tamulonis]

@Federico_Stefanato

However, AddRow() formula returns an Action , not a row (*).

@Federico_Stefanato This is a good explanation. We have discussed potentially changing this for WithName, but we have not had the bandwidth to get to it yet. We will have to spend some time thinking about if this could break existing workflows.

Turning the question around to the community. Are there places where changing this behavior would break existing flows? Do you feel like changing the behavior would be a better user experience?

[cnr]

Thank you for your response!

Is there even a way to call an action if it’s in a table? Can I add actions to various rows in a table and then call RunActions on them?

Also, isn’t it fairly inconsistent right now? For some reason the first AddRowis executed and then the second one is not? I would understand if it were both or neither, but as it stands it seems unpredictable.

[Federico_Stefanato]

@cnr

Also, isn’t it fairly inconsistent right now? For some reason the first AddRow is executed and then the second one is not? I would understand if it were both or neither, but as it stands it seems unpredictable.

Yes, this is my opinion as well.

@Federico_Stefanato

Let’s say that I’d expect an error, in this case, as we are comparing Action and Row ( Ref ) objects,

I’ll try to extrapolate the topic to a new one and see how the community would see it.

[Federico_Stefanato]

Please, follow here:

[Open discussion]: What an action (add, delete, modify) should return?

Hi everybody. The discussion started here (Why Doesn't This Formula Work? by @Connor_McCormick and followed by @Jason_Tamulonis ), but perhaps it’s a good thing to give full visibility to a topic I consider an interesting point. Have you ever had the need to refer to a just created/modified/deleted row(s)? As of now, functions AddRow(), AddOrModifyRows(), ModifyRows() and DeleteRows() return (output) an Action that - when run - will affect the selected rows. My current perception is actually…