Maybe using $$BAckupName in line 11 instead of $$BackupName as set in line 6 creates the problem ?
It should not, but still worth trying to fix that.
It did Not . But I think I need a Different solution. I need for it to copy as much of the original record to the backup Table.
is there an easier way to copy all the relevant fields from my BACKUP table from my Events Table?
I seem to have neglected a very important command, that the example from FM has for the comand
https://community.filemaker.com/GetFieldName ( Evaluate ( Credit Collection::Call Location & " Phone" ) ); Credit Collection::Phone Number.
I need to use GFN and evaluate
Your script involves capturing data from the active field.
The active field is the one that has the cursor in it.
IS this field even on the layout?
IS the cursor ALWAYS in this field when the script starts?
What triggers the script to happen in the first place?
Step 6 is your problem. It should be:
Set Variable [ $$BackupName ; Evaluate ( "BACKUP::" & $$Currentfieldname ) ]
how should i define step 11? It is still not working with your correction. As for how it's being triggered, on object Modify Script trigger.
(in the table, Events)
Also, it's still not evaluated currentfieldname, but it does grab the contents, it also ignores the ::
Yeah, my bad. Use Bruce's version.
For me I would use a much simpler system if you are just copying data. There are many ways to do this.
Have a layout based on either table that contains all the known fields you wish to copy.
Then simply set each backup field directly from the corresponding source field on the same layout. You can manage it with variables and field names like you have or incremented object names (source fields s1, s2, s3...backup fields b1, b2, b3). This could run through an loop and exit after the known number of increments are completed. You can skip empty source fields.
I do not think there is any reason to be switching layouts many times for this kind of operation.
Another option you could use a stored calculation for the backup records and re-evaluate, but that might not be the best idea for a backup. Looked up values? Go to the backup table and get source field data via ExecuteSQL calc in a script? What you are doing seems a little clunky.
Seriously clunky indeed, it's unclear what the purpose is here.
At the very least, push data using relationships designed with auto-create and stop all window popping.
thanks bruce, your example shows me where i went wrong. as for why i'm doing it this way, it was more of a test really.
I will be making a 2nd version that does the iteration method, but I wanted to see what I was doing wrong before i went ahead. I wanted to understand why X works before I went ahead and try another method.
on a semi related note, How do i make a saved list of users for email scripts?
i have some idea of how to start, but the examples I saw were only for people on the currently assigned job list, ..
Should I create a custom job list id for the group i want to send emails to?
for example, contributor group 0, are all the people that will get emailed. the other group numbers are the people on events.
is that a correct assumption?