I suggest that you post your script as I can imagine several different ways you might have written that script. Are you trying to create a series of N devices, each with one event record marking the start of that device's history?
To post a script to the forum:
- You can upload a screen shot of your script by using the Upload an Image controls located just below Post a New Answer.
- You can print a script to a PDF, open the PDF and then select and copy the script as text from the opened PDF to your clipboard for pasting here. (with this approach, you can get multiple script steps on the same line, please edit the pasted text by inserting some returns to separate those steps.)
- If You have FileMaker Advanced, you can generate a database design report and copy the script as text from there.
- If you paste a text form of the script, you can use the Script Pretty box in the Known Bugs List database to paste a version that is single spaced and indented for a more professional and easier to read format.
Per request, I'm posting some screenshots of the scripts at this point. I just tested it and it is looping properly and exiting from the loop, but data is not carrying over to the DeviceEvents table. I end up with new entries in Devices (with the relevant data) and new entries in DeviceEvents with only the autofilled fields containing any data. Is there something I need to do in order for the variables to carry over when the second script runs? If I address this will the $DeviceID variable be updated on each loop, or do I need to accomplish that some other way? Thanks for your help.
Here is the second script that the first one references. I've done some further research and it looks like I might need to utilize script parameters or just combine the two scripts.
So, I got it to work by combining the two scripts. I think that the effort to get script parameters working would be more that of tweaking a copy of one script for each device type. It also looked like defining multiple script parameters would have been challenging. I'm attaching the script that worked for anyone who is curious with one field name that is specific to my employer redacted.
I really can't tell as the print in two of your images is just too small to read....
Updated the one that is working so others can use it for reference. The answer I found from trial is that you are able to define a variable at the start of a loop with a new value each time it loops. In the above example $DeviceID is defined once before starting the loop to create the event on table DeviceEvents for the first phone the user enters. After the first phone the loop starts by creating a new entry on Devices and setting the _DeviceID_pk field for that entry as the value of $DeviceID. Each time the loop runs $DeviceID is redefined with the value for the new device being entered.
What I see seems unnecessarily complex
The basic out line for what I understand that you are doing would look like this:
Go to Record/Request/Page [First]
Set Variable [ $DeviceID ; Value: Devices::__pkDeviceID ]
Go to Layout [ "DeviceEvents" (DeviceEvents) ]
Set Field [ DeviceEvents::_fkDeviceID ; $DeviceID ]
Go to Layout [ original layout ]
Go to Record/Request/page [next ; exit after last ]
In most cases, there shouldn't be a need to copy data from a Device record to a related device event record except for the primary to foreign key pair of Set Variable/Set Field steps as a DeviceEvent record can readily access any needed data from the parent Device record.
Thanks for the feedback Phil. I definitely see a few extra steps that can be eliminated looking back at it today. I'll be doing some refining of the script as I continue to work with it.
We periodically have devices get reassigned, which is the reason for wanting to duplicate some of the fields into the DeviceEvents table. That way, even if a device is transferred to a new project, we have a complete history of what it was purchased for and where it's been.
That makes no sense. Transferring a device to a new project should link it to a different project record. It shouldn't change the device history nor the purchase details recorded in fields of the parent device record.