Greetings Fellow AppSheeters, I've been bang...

[SOMNiO_iNTERPRi]

Greetings Fellow AppSheeters,

I’ve been banging my head against the wall with AppSheet for the last couple-few weeks, believing I could figure it out, as it essentially seems rather straight-forward. However, after rebuilding an App twice, still to no avail, I think it’s now quite clear that I obviously need help.

I’m making a simple Mobile Rec Sports League Manager which uses four tables (Google Sheets) – WEEK DAYS, SPORTS, TEAMS, & MEMBERS (Players), where as MEMBERS may play on TEAMS, in SPORTS, on different DAYS (multiple combinations).

The bulk of the data is stored in the MEMBERS table as they have the most variables – Name, Photo, Team(s), Sport(s), Email, Phone, Address, Agreement to Terms/Conditions, & Signature. While the other tables store only the minimum data required to uniquely identify them. In theory the idea is to build from the bottom up and be able to view from the top down, so-to-speak.

I’ve been able to link the respective columns of the sheets and through research & trouble-shooting, chosen Enumlist as Column Type for those enabling multiple options. However, each constantly displays ALL available options in a given respective column, as I have yet to figure out which type of expression (Show_if or Valid_if or other) to use and just where to implement it.

If I want to be able to click on a given DAY and see which TEAMS play which SPORTS, including which MEMBERS, OR click on a given TEAM and see which DAYS they play, which SPORTS & the related MEMBERS, OR click on a given SPORT and see which TEAMS play, on which DAY, including the related MEMBERS, do I have to create Slices for each different view? Or is that even the way to go at all here?

It feels like I’m almost close enough to taste the solution, but it seems what ever options I choose just don’t cut it. Comments, criticism, & suggestions alike are welcome, please.

Thanks.

[Aleksi_Alkio]

It sounds you should do the app structure with related tables. The Team might be the Parent where the others would be Childs for that. You can read more about it from here…

help.appsheet.com - References Between Tables References Between Tables help.appsheet.com

[SOMNiO_iNTERPRi]

Thank you for the quick response & reference Aleksi. I thought I’d try my hand at it again with this info before pestering more.

But I’ve sourced this reference before & unfortunately it seems the descriptions are just ambiguous enough to keep one from creating the necessary accurate relationships between tables in their own App.

Is there a specific reason you say the “TEAM” table should be the “PARENT” in my App scenario??

Especially when I noted that the “MEMBERS” table is storing the most detailed & variable information [e.g. Sport (Type), Team (Name), (Member) Name, Photo, Email, Phone #, Address, Terms & Conditions (Link), Agreement, (Y/N), & Signature] … ??

[Aleksi_Alkio]

I believe the answer is quite simple, actually. Both the member and match (Day) belongs to team. And another reason is… the member can basically belongs to more than one team. In this season he belongs to this team but next year he can belong to another one. If team belongs to more than one member, it sounds weird.

[Aleksi_Alkio]

And the UX is easier to construct… One dashboard view where you can see all teams… members for that team and match list for that team.