How do I change data for multiple reference rows from a row in another table?

Iโ€™m stuck on trying to change data on one table based on changes from another. For example, I want to make a row in the Filters table become Inactive based on when a row in a reference row (Properties) becomes Inactive. I created an Action Data: execute an action a set of rows with the formula: SELECT(Filters[Property ID], [Property ID] = [_THISROW].[Property ID]), but it doesnโ€™t work correctly.

Also, there can be multiple Filters referenced to a single Property. And I want all of them to be inactive when the Property becomes inactive.

Any suggestions are helpful.

0 3 1,325
3 REPLIES 3

You need to specify a List of key values for the Filters table. Is [Property ID] the key column in the Filter table?

By the way, the FILTER() expression is very similar to SELECT(), I prefer to use it whenever appropriate, such as this case.
SELECT(Table[key column], โ€ฆ) is equivalent to FILTER(Table,โ€ฆ)

FYI: the FILTER expression is actually a port of the select expression. When you use FILTER, itโ€™s just another way of writing SELECT() - when AppSheet is computing the formula, the FILTER() syntax is transposed into a SELECT. Just fyi.


Also another note to @Andrew_Hock:

In your post you put a sample SELECT():

While AppSheet does not require that all column names be unique, there are times when it could (perhaps it should enforce them, but thatโ€™s a discussion for another time), I have seen problems with some formulas not working solved by making column names different among tables.

For instance:

If I had an invoice table, with Invoice_Details, Invoice_Notes, and other child tables, I wouldnโ€™t call the reference column in each of the child tables โ€œInvoice_Linkโ€ or โ€œInvoice_IDโ€; instead I would individualize each of them (Invoice_Notes_Invoice_Link, Invoice_Details_Invoice_Link, etc.).

AppSheet has no limit to the length of a column name (that Iโ€™ve found), so you can get really detailed with the column names. Not only will this help you to be able to read your formulas and understand exactly whatโ€™s happening (without needing to know where it lives, context itโ€™s used, etc.), but also any queries run on the back end will pan out correctly.

While the following arenโ€™t direct examples of how to do what you are looking to do, they will give you some examples of how you might accomplish updates of child records; the system and mechanisms necessary are the same, so these can give you some hints and ideas of how to accomplish things.

Top Labels in this Space