Inline view setup

behavior
(Neal Mf Harper) #1

I have many to many tables with a twist that has me stuck:

Items table<->bridge table<->photos table

If I only have one photo the inline items show as needed… however if I have multiple versions of the photos I can’t determin how to link up properly, right now only one of the rows for the photo return the inline view.

We name the versions with suffix like _0001, _0002.

The version names do not exist in my Bridge Table as they are created throughout the day, is there a way to generate them in the bridge with the associated items of the original photo?

OR is there a formula solution to create a custom inline ref view of items based on the original photo name?

My photo version name is the current key for the photo table, as it is unique, the original photo name is no longer unique due to versions of photos but both columns exist, one for photo ID and one for photo version ID. I feel like this is doable, yet over my head.

Thanks everyone!

(Tony Fader) #4

Hi @Neal_MF_Harper. Would it help if you had a separate Photo Versions table, where each row has a reference to a particular row in Photos? Then you could create a column in Photos that has the most recent photo, for example using a formula like MAXROW("Photo Versions", [Photo] = [_THISROW]).

1 Like
(Neal Mf Harper) #5

Thanks Tony,
I had the data separately originally, a table for photo request connect to the versions of requests, but it created a viability issue for managers that need to view and update the Google sheet including both sets of info.

My secondary dilemma with the segregated data was my items inline view only appeared on the request table, not in the version view, only related to the request. In the detail views of the photo versions were not directly related to the items, so I couldn’t determine how to show an inline reference table for a grandchild type relationship.

Thanks you for your feedback!
Neal

(Alex Meraru) #6

What is it that the app does?
Walk me trough this bit.
I’m a novice but I have a feeling my app has what you want.
Try to be less tehnical :wink:

(Neal Mf Harper) #7

Hi Alex!

We take pictures of items. Many combinations of items per picture. An item can appear in many pictures and many pictures can include the same item. That’s my ‘many to many’ relationship that needs a bridge table.

The twist is sometimes we need to take multiple versions of the same picture. This ruins my unique picture ID, so I end up with another layer of relationship that keeps me from showing the items inline table in the newest ‘version’ table, where its needed the most.

Thanks for your time!
Neal

(Alex Meraru) #8

Hi Neal!
A. Do you need multiple versions of the picture or just the latest?

  • just update it and keep things simple :slight_smile:

B. If you do, then I don’t think there is another way other than the one suggested by Tony.
My version is kind of the same but a bit longer.
3 tables:

Picture ID with [Picture ID],[Latest Version]
Versions with [Key],[Picture ID],[Version],[Time Stamp] - ref to Picture ID
Your Table ref to Picture ID and getting the value from [Latest Version]

I meant to test it to see how it behaves but for some reason, at the moment, I can not create a new app as I’m getting an error trying to connect the spreadsheet :frowning:

(Neal Mf Harper) #9

Thanks for the feedback Alex!

Unfortunately we do need all photo versions, splitting the info about the shots into separate sheets makes it messy for managers when trying to add new version records in the spreadsheet backend. I may need more coffee to figure this out…

Have a great day!
Neal

(Alex Meraru) #10

But that might be your problem!

Why are they working on the back end instead of using the desktop version?

(Neal Mf Harper) #11

Dang humans, always causing process issues! I am seeking robot replacements for management if you have any leads.
:slightly_smiling_face: