Can you do multiple REF_ROWS from a single parent table to a single child table?

[Frank_fjftech]

I have a long form view of my parent table, with photos and location data added to multiple questions. Previously I've used ref columns to a child table with the data. Multiple ref columns to the same child table works fine.

However, using ref columns in the parent table annoys my clients, because the return to the parent table (form) is always to the top of the form, not the point of the ref column.

I've switched to  the ref column on the child table, and REF_ROWS on the parent table. It's a better user experience. However, I currently need a new child table each time I link to it. I need up to 20 links to it per parent form.

Multiple identical child tables works, but it's a time consuming, inelegant solution.

Does anyone know a better solution?

Thanks

[Marc_Dillon]

I think your understanding of references might be a bit off, but I'm not really sure. Can you describe a bigger picture of what you're trying to do with these 2 tables? Some data examples and/or screenshots would certainly help.

[Frank_fjftech]

Thanks Marc. I'm sorry that the description is a little confusing.

Here's a screenshot to demonstrate: (Sample App, Sorry, I can't share client data)

Above is the parent table, and the form view of that table of it on the right. Most questions require a photo. Each photo requires date taken, who took it and when. So the photos require a child table.

Question 16's photo is a ref from the ParentForm to Multiphoto via an EnumList, to allow multiple photos.

Question 17's photo is via a ref to ParentForm from the table "Photo17". This is added to the form via Related Photo17s

After the user takes photo 16, they return to the top of the ParentForm form, not at the position shown the app preview on the right. That annoys a lot of my clients, and results in low app uptake. When they take Photo17, they are returned to the position on the form they left from. They don't lose their place on the form. Much happier clients. 

The table that takes question 16's photo is "MultiPhoto". I can reuse this table for Questions 1 through to 25. Appsheet handles that really well. But the way Photo 17 is taken requires a new photo table each time. The app I'm developing has 3 forms with about 20 photos each. The clients prefer photo 17's method, but if I use that, I'll have to add about 60 tables to the App. Hence the question. Can I use questions 17's photo method with less that 60 tables?

[Marc_Dillon]

I would move the question identifier from the parent table to the child photo table. That way you can re-use the same table for all of your photos. This also makes your app more scalable, because when you need to add more questions, you don't need to adjust the column structure, just add more records.

This might require some larger re-working of your app workflow to be a manageable UI/UX. For example, you might auto-generate all child record at the time that the parent record is first created (1 for each question), and display them as an inline view on the parent's detail view. Consider using a template table that holds 1 record for each question, and use this to copy from every time a new parent record is created.

If a question requires more than 1 photo, include an easy copying action for that question's child record.

Check out inline-attached actions, as well as INPUT() to help make the UI/UX better.

[Frank_fjftech]

I can see where you are going with this. It sounds like a great solution, both for myself and many other Appsheet users. Is there an example that can fill in a few of the details and make it a bit easier to implement?