Richmilnix

passing variables between table occurrences

9 posts in this topic

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.

Share this post


Link to post
Share on other sites

Posted (edited)

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 by comment

Share this post


Link to post
Share on other sites

Posted (edited)

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 by Richmilnix
typo

Share this post


Link to post
Share on other sites
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.

1 person likes this

Share this post


Link to post
Share on other sites

Posted (edited)

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 by comment

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Similar Content

    • By Richmilnix
      I'm reframing a question that I posted in a confusing way. Using variables seems so simple to me, but I know I'm missing something. I'll just post exactly what I'm trying to do so you guys can tell me why it isn't working.
      The project is a db that will handle shift schedules for employees. In the one-day view I'm looking at, the essential live field is a global date field called gDate_of_work. A portal is looking through to related records and returning a list of employees (from a table called staff_schedule_match), identified here by unique serials, who are scheduled to work that day. There is a second portal, located on the same layout, that is (correctly) showing a separate related list, of employees who are available to work on the day of the week.
      I, of course, want to be able to click on the name of an available employee and pass her serial number, along with the date in the global date field, to a new record in staff_schedule_match. In the distant past, I've sometimes solved this by opening layouts in offscreen windows and having extra fields dedicated to this data transaction, sometimes even by using the computer's clipboard (i.e. copy/paste).
      The script I'm trying to execute here goes:
      Set variable ($shift_add_nuid; employee's serial number from related record two) Set variable ($work_date; date displayed in this global date field) Freeze window Go to layout staff_schedule_match New Record Set Field (staff_schedule_match:nUID; $shift_add_nuid) Set Field (staff_schedule_match:StartDate; $work_date) Set Field (staff_schedule_match:EndDate; $work_date) Commit Record Go to layout (original) Refresh window Stepping through the script watching Data Viewer, I can see that the correct data is getting loaded into the variable values, but I can also see that the destination fields show up with an Unrelated table error. I don't understand why - I expected the behavior to be destination-agnostic, like my computer's clipboard, where if I copy some text in an email, I can paste it into a word processor or a browser or whatever.
    • By Asu
      Hello, I have a Case calculation that does not return what I expect
      wd1 = width of image in container1 , ht1 = height of image in container1
      wd2 = width of image in container2 , ht2 = height of image in container2
      A script would open up a popup window sized to the parameters of the image in the container. This is how it starts:
      Set Variable [ $contfield; Value:Get ( ScriptParameter ) ]  //which is the name of container1 or 2 which it gets correctly Set Variable [ $ht; Value:Case ( $contfield = Untitled::container1; Untitled::ht1; $contfield = Untitled::container2; Untitled::ht2; "ERROR") ] Set Variable [ $wd; Value:Case ( $contfield = Untitled::container1; Untitled::wd1; $contfield = Untitled::container2; Untitled::wd2; "ERROR") ]  The calculations return "ERROR". Which I don't understand as I would expect $ht/wd to be set to the corresponding numbers in ht1/2 and wd1/2. What am I doing wrong?
      Thanks
    • By the Otter
      As most people here probably know, the Let ( ) function can be used to define a Local variable. As such, it is possible to build a custom function that defines such a variable, and it is further possible to set said variable to a value including itself. An example would be the following custom function, ErrorList, consisting of the following calculation:
      Let ( $ErrorList = List ( $ErrorList ; Get ( LastError ) ) ; "" )
      If a Set Variable script step sets the same variable as a custom function like the one above, e.g.
      Set Variable [ $ErrorList ; Value: ErrorList ]
      …the script step will run appropriately, so long as the contradictory variable—in this case, $ErrorList—is not yet defined. However, once this variable has been defined, executing the preceding script step will cause FileMaker 14 (and perhaps other versions) to suffer an Error #1213 and crash the application. The workaround for this behavior is to have the Set Variable script step set a dummy variable, e.g.
      Set Variable [ $x ; Value: ErrorList ]
      Even if $x is not referenced anywhere, having a script call the ErrorList function passes the variable $ErrorList to the script’s own context, thus allowing its value to be accessed by later steps in the same script (including subsequent calls to the ErrorList function itself).
      In FileMaker 15, this behavior has been changed: local variables defined within a custom function are now valid only within the scope of the function itself, including any recursions. While this alleviates the problem of application crashes, it also results in unexpected behavior when scripts written in earlier versions of FileMaker rely on custom functions to set local variables. When migrating to FileMaker 15, each affected script step must be updated to set the target variable explicitly instead of relying on the custom function to do the work. In other words, the code:
      Set Variable [ $ErrorList ; Value: ErrorList ]
      …which proved fatal in FileMaker 14, is now required grammar for FileMaker 15: FileMaker 15 believes that what happens in the function stays in the function, instead returning the result of the calculation to the variable defined in the Set Variable script step. The FileMaker 14 grammar,
      Set Variable [ $x ; Value: ErrorList ]
      …thus sets $x to the intended value of $ErrorList while leaving the value of $ErrorList as null.
      Unfortunately, this cannot work effectively in a mixed-installation environment: the FileMaker 14 grammar leaves FileMaker 15 clients with unintended null values; the FileMaker 15 grammar causes FileMaker 14 to crash. When upgrading all users to FileMaker 15 is not feasible, the best workaround is to use the FileMaker 14 grammar, then once all relevant script steps are complete, check the value of the intended variable (e.g. $ErrorList) and, if empty, set it to the value of the dummy variable (e.g. $x).
       
      ErrorTest.fmp12
    • By fm8443
      I am trying to open my (local) FM 14 Pro file [which has an auto-exec "Import Script"] but the script needs a variable file name.
      How do I pass this variable file name into Filemaker at 1) the time of the file open or 2) at the time of running the script (if I switch to manual execution)?
      Is #1 by using the fmp:// syntax from a web browser external to FM?  (or is that syntax just for use when invoked from INSIDE a FM file?)
    • By Rook183
      I am sure this is one of those simple ones… that has me bamboozled for nearly 2 days now.
      I need to limit access of my users viewing only a limited set of "Company" records after they log in. The companies that they are allowed to see are listed in each respective user's profile.
      My opening script goes to the user's profile and creates a global variable for each company that they are allowed to view.
      When I go to the "Manage Security > Edit Privilege Sets > Records > Custom Privileges > Limited > Script", and use any of those variables (e.g. $$Company01"), the records table returns no records at all (i.e. as if there were no matches). When I test the script and use text for any one (or several) of those companies by name (e.g. "ACME PTY LTD"), the access rules work perfectly.
      To be clear: The global variables themselves are correct. I know this this because they work in other scripts absolutely perfectly, so the variables DO match the names in the field.
      The script looks like this:
      $$Company = Table Manufacturer or 
      $$Company01 = Table Manufacturer or
      $$Company02 = Table Manufacturer or 
      $$Company03 = Table Manufacturer or 
      $$Company04 = Table Manufacturer or 
      $$Company05 = Table Manufacturer
       
      In every respect, the variable matches the actual text, but I can only imaging that there is a problem with my syntax?
       
      Please advise.
       
      Many thanks