Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 2814 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

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.

Posted

Check if your "staff_schedule_match" layout is pulling the data from the right table.

In FileMaker everything is context-dependent, aka not "destination-agnostic", unless you do SQL calculations. 

Posted

I know it's hard to tell because I threw so much information in there, but staff_schedule_match is one table, containing shift data that looks like

StartDate: 3/22/2017
StartTime: 7:30 AM
EndDate: 3/22/2017
EndTime: 4:45 PM
nUID: V204

A second table is the one I'm working in, staff_schedule_interface, intended to be the neutral "window" through which employees view and print the data in above (organized by day, by week, or by name).

Given the use I described above, I don't understand what context I should establish.

(At least once, I solved a problem by creating a field called "1" in both tables, defining it as a calculation whose value was 1, and using that to build an "everything is related to everything" relationship. Not proud of that.)

Posted
23 minutes ago, Richmilnix said:

Go to layout staff_schedule_match

That's not how the Go to Layout [] step looks like. If you take a look at your actual script, you'll see it's structured like this:

Go to Layout [ “Layout Name” (Table Occurrence Name) ] 

In your example, that should translate to:

Go to Layout [ “staff_schedule_match” (staff_schedule_match) ] 

Judging by your error, you are seeing something like this instead:

Go to Layout [ “staff_schedule_match” (Some Other Table Occurrence) ] 

because the layout named "staff_schedule_match" is defined to show records from Some Other Table Occurrence.

 

BTW, this has nothing to do with variables. You will get the same error if you try to set any of the fields to a constant value.

Posted

I might have confused things (again) by typing the script manually. The script step actually reads

Go to Layout [ “staff_schedule_match” (Date_match) ] 

where Date_match is the named relationship through which my portal is seeing the employees working on a given date.

. . . and therefore, I now realize, I need the relationships in the script to be defined through Date_match as well!

I gotta admit, I still get confused in trying to map this out. But the solution is working now. Thanks for your input.

Posted
12 minutes ago, Richmilnix said:

where Date_match is the named relationship

No, There are no named relationships in Filemaker. Date_match is the TO to which the layout named "staff_schedule_match" belongs. When you execute this step, you are placed in the context of the Date_match TO. I don't see your graph, so I am not sure what exactly that means. And I am afraid I don't follow your initial explanation well enough to understand what you want to do. But I can tell for sure that you are trying to set fields in the staff_schedule_match TO, while you are in the context of the Date_match TO - and since these two are unrelated, you are getting an error.

And I can also say that relating them artificially is not the solution, because while you are in Date_match, the only record in staff_schedule_match you'll be ever able to modify is the first one.

Posted
Quote

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.

This is still confusing and still jumping into the middle of something without describing the basics.

Please begin by describing your data structure. What tables are involved; what does your graph look like.

This topic is 2814 days old. Please don't post here. Open a new topic instead.

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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.