My goal here is to write a database with tidier relationships than I've used in the past, so I'm intending to use discrete table occurrences of the same data. Here's the roadblock:

In layout 2_week_schedule, I have 14 portals that display a staff schedule (two weeks' worth) and can't be edited. My goal is that a logged-in administrator can click on the date field of any one of those fourteen days and go to a layout 1_day_schedule that is displaying the same information, though with more details and one day at a time.

The underlying table of each layout is the same, though the layouts are based on different TOs.

I wrote this with a script trigger in the date field in 2_week that fires a script to copy its value as date to variable $date, switch to the 1 day layout, and set the pertinent date field there to variable $date (and then commit).I don't know if it's my error, but I think of variables as being like my computer's clipboard - any value can be copied & pasted to/from. But the script fails with the message The operation could not be completed because the target is not part of a related table.

I did try a simple redundant relationship (connecting the two pertinent fields), but that was a hail Mary, and didn't do the trick anyway. Is there a better way to accomplish what I want? In short, I want administrator who's scrolling through the existing schedules to be able to look at any date where she wants to make a change, click on it, grab its contents, and be brought to a more flexible interface where its contents get inserted into a portal that will then show her the results.

This file is web-accessible, so I can post its address if it helps to see what I'm talking about.

19 hours ago, Richmilnix said:

The underlying table of each layout is the same, though the layouts are based on different TOs

Why is this a good idea? It seems it only adds complexity (as demonstrated by your question).

 

19 hours ago, Richmilnix said:

the script fails with the message The operation could not be completed because the target is not part of a related table.

Apparently you are not setting the field of the TO of the layout you have moved to. If you started on a layout of TO X (the 2-week view) and then moved to a layout of TO Y (the daily view), make sure your Set Field[] step is targeting the local field Y::ViewDate, not the unrelated field X::ViewDate.

--
BTW, your mention of the need to commit records suggest that the dates are not global. They need to be, otherwise one user selecting a time slot to view selects it for all users.

Added: Also, since global fields are accessible from anywhere, without a relationship, this would also eliminate the error you're complaining about.

 

Edited March 17, 20178 yr by comment

You know what, I have only myself to blame - years ago reading about Anchor-Buoy structure I Was really attracted to the notion of discrete TOs coupled by a slew of relationships - but each time I try to implement them I make sort of a hash of it. Thanks for your input.

Edited March 17, 20178 yr by Richmilnix
typo

56 minutes ago, Richmilnix said:

the notion of discrete TOs 

You've mentioned that twice but it is not clear to me what you mean.  Is your goal to have just one TO per base table?  And if so, why?  What specific problem would that solve for you?  Or is an abstract notion?

Abstract notions is what gets a lot of us in trouble, premature optimization, unneeded modularity,... that kind of thing.

2 hours ago, Richmilnix said:

years ago reading about Anchor-Buoy structure I Was really attracted to the notion of discrete TOs coupled by a slew of relationships

I am not really a fan of A/B, but even in that method the rule is that all layouts of a base table belong to a single TO (the "anchor" TO) of that table.

--
P.S. Please note the addition to my previous answer.

 

Edited March 17, 20178 yr by comment

All right, let me try to answer without digging myself any deeper.

First of all, I'm not arguing with you guys. Clearly, I overcomplicated things. But since Wim asked what I was after:

I'm a part-time developer who only dives back into FMP every few years when I have a problem that needs solving. That means that I don't spend a lot of time thinking about logical schema. As my projects began to grow more sophisticated and more interrelated, I found that my relationship maps were sprawling - mostly because what had started off as a db hosting events was now also hosting staff schedules, and now was also incorporating POs and invoices, and everything seemed to be related to everything and my relationship graph looked like a child's drawing of a millipede cocktail party.

So in short I was trying to neaten things up. I'm still (I guess) a bit mystified about some of the complexities of relationships. Even after straightening out my separate TOs, I still have questions about passing variables, so I'll post back later about them.

Make sure to read this:
http://www.nightwingenterprises.com/Resources/approaches_to_graph_modeling_en.pdf

1 hour ago, Richmilnix said:

Even after straightening out my separate TOs, I still have questions about passing variables, so I'll post back later about them.

Passing variables is something you do between scripts and has nothing to do with TOs so there is some really fundamental confusion in your mind that needs to be cleared up, otherwise you'll come up with answers that don't fit the question

You're right; I was conflating two issues (because I thought my variable trouble was stemming from my mixed-up TOs). Reframing my question in a new thread.