IIUC, you can do this:
While in the context of the modified record, retrieve the TO of the changed field with
Get ( ActiveFieldTableName )
Concatenate that with "::id" (or whatever your primary key's name is) and pass it to GetField().
Okay, first, there's no such thing as the pk of a field. Records have keys; fields do not.
I will therefore assume that what you really want is the key of the related Hours record, as filtered through the 7 "by day" relationships. You don't mention how you're attempting to capture it, or what isn't working, but something like this should work:
Set Variable [ $pk ; Value: Mon_Hours::pk_hours_id ]
Note that you will need to do either one of two things: Either code your script with a series of If statements to pick the correct relationship, or use GetField ( ) or Evaluate ( ) to fetch the value based on a calculation. For example:
Set Variable [ $day ; Get ( ScriptParameter ) ] // where the parameter is "Sun", "Mon", "Tue", etc.
Set Variable [ $pk ; Value: GetField ( $day & "_Hours::pk_hours_id ) ]
Then proceed to use the $pk value to create your change log record.
Note that this will not work if the key field is different because there are no matching records. This may be what's hosing your script in the first place; if no related record exists, then there's no key to fetch.
I am going to try this. I was trying to concatenate, but was doing it a goofy way that I should've known better.
Thanks for the "fields don't have primary keys lesson" mike. I was trying my best to describe my issue, be brief as possible, and just happened to miss that little detail. Sorry, I'll try not to do that again.
On a side note, this sort of abstraction is why I give all my primary key fields, in all tables, the same name. We used to use __P, now we use __ID, but "pk" or "id" would serve just fine.
You can tell (or should be able to) the table name from the table occurrence name, so repeating the table name in the primary key field name isn't helping you much, if at all. It does, however, mean your functions need to be "tweaked" any time you want to use them for a different table.
Just food for thought, FWIW.
What I want to do , is to create a change log for every record created, so if the user changes their time for an account/day combo, I can see when it was changed, what it was before the change, and what it is now. I have a relationship set up to do this.
I suggest you take a look at Ray Cologon's UltraLog demo (NightWing Enterprises - UltraLog v2.x Audit Logging Demo for FileMaker Pro) which is a very good audit trail method.