Hello Again.

I am trying to sum a column values in another table if meeting a simple Yes/No Status.

The idea is simply to sum if status column value is “Rentado”.

Can sum without the condition.

Result should be 1309 and I always get 0.

Hello Again.

I am trying to sum a column values in another table if meeting a simple Yes/No Status.

The idea is simply to sum if status column value is “Rentado”.

Can sum without the condition.

Result should be 1309 and I always get 0.

Hi @Isaac_Askenazi !

Maybe you could try this ?

```
thisRow.Areas.Filter(Estatus.Contains("Rentado")).M2.Sum()
```

Didn’t work.

Does it have to do with the fact that Estatus (in Areas table) is a formula that comes from my table with lease contracts?

Maybe try:

```
Areas.Filter(CurrentValue.Estatus = "Rentado").M2.Sum()
```

Yes, but that’s not the formula I suggested …

(Note that `Estatus`

here is in fact `CurrentValue.Estatus`

)

… which

- should take the
*list of rows*in your field`Areas`

( →`thisRow.Areas`

) - and filter it to only keep the rows where the status would be
`"Rentado"`

( →`thisRow.Areas.Filter(Estatus.Contains("Rentado"))`

. - From that filtered list of rows, you can then access their respective
`M2`

values

( →`thisRow.Areas.Filter(Estatus.Contains("Rentado")).M2`

) - And then
`Sum()`

those values`thisRow.Areas.Filter(Estatus.Contains("Rentado")).M2.Sum()`

The formula you used is different …

```
thisRow.Areas.M2.Filter(Areas.Estatus.Contains("Rentado")).Sum()
```

… As you begin by acting on a list a numbers ( → `thisRow.Areas.M2`

)

1 Like

@Pch , your explanation is truly outstanding. However, there is a slight ambiguity in the original topic regarding whether the formula should be applied to the entire `Edificios`

table or to each individual record within it. Further clarification from the author would greatly help in providing the most suitable solution.

If the intention is to execute the formula once on the second table and store the result in the first one as a record, then my suggestion would indeed be applicable. However, if the `Edificios`

table contains a relation column called “Areas,” then your suggested formula should function as expected.

To truly grasp the essence of the problem at hand, it would be of immense benefit for the author to delve further into the details and provide an explanation regarding the existence of a relation column named “Areas” to the second table. This particular clarification holds immense significance as it allows us to provide the right solution to the right problem.

Let’s keep codawing!

The intention was to execute the formula on the table that aggregates the information of Buildings. Where I could see the snapshot of the full building total area, leased and available.

That information comes from the detailed, floor by floor table of Areas. And the information of which Area is or not leased comes from the table where I have the lease contract information.

Just for learn, can you explain the difference of both formulas? Why the first doesn’t work and the second one does?

Hi @Isaac_Askenazi,

It’s all about scope.

The first formula can be interpreted as:

**Areas**(take the whole table).**M2**(take just the one column).**SumIf(Estatus.Contains(“Rentado”)**

By selecting a single column **M2** you have limited the scope of the formula. The SumIf cannot work because it cannot access the other columns to make a relationship. It has no knowledge of **Estatus**.

If you wanted to use SumIf in this context you can only worked with the data from **M2**. For example you could say:

This will take all of the information from M2 and sum it together if the CurrentValue meets the criteria set, in this case if the value is greater than or equal to 2. Still useful if used right but not what you needed.

The second formula works because it applies the filter first.

**Areas**(take the whole table).**Filter(Estatus.Contains(“Rentado”)**(apply a filter to get us only the rows we need).**M2**(now take just the one column of our filtered table).**Sum**(add them up)

I hope that this helps.

All the best

Dale

Yes. Perfect explanation.

Thanks !

Ah, it seems my initial observation was indeed accurate . The first table labeled “Edificios” does not contain a column named “Areas.” This is precisely why I believe @Pch may have overlooked the issue you are attempting to address. @Pch mistakenly assumed that there was a relationship between the two tables and that your intention was to apply the formula to each individual entry in the “Edificios” table. Hence, @Pch suggested utilizing `thisRow.Areas`

instead of simply using Areas .

Sorry if my previous response came across as impolite, as that was not my intention in the least. Anyways, Let’s keep building

My pleasure @Isaac_Askenazi !

@Mahmoud : I might have taken a wild guess, I agree but I think you could take a closer look at the screenshots …

It’s not because we don’t see the `Areas`

relation/linked relation field that’s it’s not there … And it’s also not because the formula editor only says `Areas`

that it doesn’t imply `thisRow.Areas`

.

If you look at the icon next to `Areas`

you’ll see that `Areas`

already returns a list of row references and not a whole table.

Meaning that in `thisRow`

there’s a field called `Areas`

currently returning a list of rows one wants to use and manipulate… Hence `thisRow.Areas`

.

Here’s another example:

… where:

- The 1st
`Filter()`

is used on`Weekdays`

which is in fact`thisRow.Weekdays`

(a relation field) - The 2nd
`Filter()`

is used on`thisRow.Weekdays`

… which is the exact same relation field as previously but just fully written. - The 3rd
`Filter()`

is used on the table`Weekdays`

(look at the different icon) storing the weekdays returned by the relation field`Weekdays`

1 Like

Wow, that’s really cool ! I had no idea about the icon thing. It’s great to know that Coda uses icons to help us distinguish between relations, tables, etc when writing formulas. This means we don’t have to worry about displaying hidden columns and scrolling horizontally.

Thanks for your time @Pch. Your explanation is clear as always!

My pleasure @Mahmoud !

And yes those icons, while a bit small (so easy to overlook ), are more than very helpful to write and/or troubleshoot formulas .

Not only do they qualify the returned data type (text, number, boolean, etc…) but they also quantify it (a value vs. a list of values)

So it’s always a good thing to keep an eye on these small visual hints/cues Coda gives …

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.