Please help with a "logic" expression

[Jake_Naude]

Evening everyone,

Here’s one for someone looking for a brain teaser!

I haven’t attempted the expression yet cause I haven’t yet figured out the logic!

Hope someone can help?

I’m looking for the logic and an expression that will look at my survey table and identify the “shared” cable routes into branches in the [branches] column.

Survey position 1 (red number below) is such a shared cable route example where I would use 1 survey form to capture all 9 cables in an EnumList in [asset_name] and an action would split the survey into 9 individual rows (each with one [asset_name] extracted from the EnumList.

The form does the EnumList thing nicely so don’t need help with that.

The orange cables in surveys 1,2,3,6 would need to be Banch 1
The green cables in surveys 13,14 would need to be Banch 2
The blue cables in surveys 17,18 would need to be Banch 3
The remaining purple cables don’t need branches.

Here’s the scenario:

I’m surveying a network cabinet, wi-fi points and cable routes in a building:

1 network cabinet (ZDC01)
9 cables (CAT01-CAT09)
9 wi-fi points (LPR01-LPR09)

This is a small sample. A full survey will have many more cabinets, cables and wi-fi points.

Thanks in advance…

Here’s an extract of the survey table - though the data doesn’t match the above example.

[Austin]

No idea what any of this is but I am interested in the response.
So basically you want to know the optimal path to survey your items(in very simple terms)?

[Jake_Naude]

Hi @Austin_Lambeth,

Not so much the optimal path but looking to use the answer to reduce the number of photos shown in the post-survey report and it’ll allow me to organise the information flow in the report. i.e. I’ll only need to show one photo per shared-cable-route-section and also present all the shared cable routes first, then all the single cables…

The current report shows all of the CAT01 survey photos (up to 30) then all the CAT02 survey photos and so on so I’m ending up with a list of 100’s of pages.

Bringing in the shared-cable-route thing should reduce the report significantly…?

[Bellave_Jayaram]

I would recommend use of multiple tables and relationships to do this rather than a single table.

[Jake_Naude]

Thanks @Bellave_Jayaram,

Could you give me a very brief outline of what the structure of that might look like…?

[Bellave_Jayaram]

You may be constrained by the business problem, I am not sure - you are surveying rather than planning a network design. Anyway, what I would suggest is to have a table for network Cabinets and have all relevant columns plus two related tables, Cables (child table with isPartOf set to TRUE) and Wifi Points (grandchild table). Cables may itself have a child table of Wifi Points with isPartOf set to TRUE. It then becomes easy to figure out the branches and what assets belong to each branch.

[Jake_Naude]

Bellave_Jayaram:

what I would suggest is to have a table for network Cabinets and have all relevant columns plus two related tables, Cables (child table with isPartOf set to TRUE) and Wifi Points (grandchild table). Cables may itself have a child table of Wifi Points with isPartOf set to TRUE. It then becomes easy to figure out the branches and what assets belong to each branch.

Hi @Bellave_Jayaram,

I’m surveying planned cable routes from a “desktop” design. The survey is intended to validate the theoretical design.

Your proposal sounds interesting. I’ve not used that approach or isPartOf before… I’ll start reading up on it and will report back… Cheers…

[Jake_Naude]

Bellave_Jayaram:

child table with isPartOf set to TRUE

Hi @Bellave_Jayaram,

Is there an AppSheet doc that discusses isPartOf that you could point me to…?

I’m looking but can’t find it…?

[Bellave_Jayaram]

help.appsheet.com

References Between Tables

Learn about references, when to create them, and how to use them so your data makes sense.

[Jake_Naude]

Thank you Sir…

[Jake_Naude]

Hi @Bellave_Jayaram,

I’ve taken this from the Refs Between Tables doc…

There are some limitations of which to be aware:

• A table can only have one Ref column marked IsAPartOf (a row can only be a part of one other row).
• Actions are not supported within forms. Inline views based on reverse references in forms will not display actions or trigger actions based on view events.
• Canceling a form with pending line item adds/edits also cancels those adds/edits.

I currently use actions OnFormSave to take the EnumList in the form and use INDEX([asset_name],n) to extract the individual asset names as another action creates additional rows for each EnumList item.

I have it set up this way so that when I survey a cable route that has n cables in it, I only need to survey once and the actions then produce n rows.

Does point two above suggest that that may not work if isPartOf is TRUE…?

[Bellave_Jayaram]

No, I don’t think so. If you have relationships, you just have to make sure to populate the appropriate key to the parent table row in the ref column of the child table.

[Jake_Naude]

Hi @Bellave_Jayaram,

Thanks… I’ll give this a try and will report back… Cheers…

[Jake_Naude · Accepted solution]

Bellave_Jayaram:

what I would suggest is to have a table for network Cabinets and have all relevant columns plus two related tables, Cables (child table with isPartOf set to TRUE) and Wifi Points (grandchild table). Cables may itself have a child table of Wifi Points with isPartOf set to TRUE. It then becomes easy to figure out the branches and what assets belong to each branch.

Hi @Bellave_Jayaram,

I took the isPartOf question away and prodded it around a bit. From what I can make out - mostly because of the rigid nature of the rf_design table that underpins the app and it’s “unusual” structure I figured that isPartOf wasn’t going to fit. The rf_design table doesn’t lend itself to Adds or Updates.

Having said that, isPartOf sounds exactly what I need for a sister app I’m starting imminently, where I have complete freedom over the design table - in fact, large parts of the design will be done on-the-fly and isPartOf sounds perfect for that!

This thread started with the issue of building “branch logic” into the app and I think I now have a way around the issue. Thank you for for giving me the missing piece to my puzzle a moment ago over in Preventing an app formula / InitialValue firing when a row is copied.

Here’s how I’m working around the issue:

• the survey form now allows the Surveyor to advise when a branch(es) is reached.
• a computed branch number is allocated for the current and any other branches.
• an EnumList assigns branching cables to the branch number
• Selected items are subtracted from the initial EnumList of cables
• as the survey progresses the current branch shrinks and knowledge of branch starting points grows
• an XY map view presents Surveyor with all available (incomplete) branch starting points!

I still have a few corners to turn but this approach is looking promising.

Here’s a little preview for the survey form “branch logic” workaround:

Cheers…