5.5 was soooooo long ago!
Create a field in both files and fill it with a constant value, ie the
same value in both files and in all records. Create a relation from
the child file to the parent file using this field. Then create global
fields in both files, when you are ready to make a new record in the
child file, populate your global with your real key value, go to the
child file create your new record and fill the key field with the
global value which is available now via the constant relationship. You
should be on your way. :)
Hope I am remembering this sequence correctly!
Jens
Jens Selvig
...Lost in Montana...
On Jan 20, 2008, at 2:42 PM, Nicholas Geti wrote:
I am running FM 5.5.
I had problems with all three of your suggestions.
1. A script in the child table will create a new record but it needs
the key value which can only be passed into a Global variable from
the parent script. Then issuing another SetField() from the parent
script will write over the current record in the child. If there is
more than one record with the same key, the parent will then always
replace the first record. I could not find anyway to step through
the child records to the one I want.
2. Cannot import from the parent. Remember that there is a relation
between the parent and the child. If I am in the child, I would need
a relation back to the parent in order to see any fields in the
parent. This gave me lots of trouble actually trying to make it work
so I gave up.
3. The portal technique was a mess. I couldn't get it to show more
than one child record in the parent window.
After a lot of hassle I finally got something working. From the
parent I used SetField() for each field in the child record to
create a new record. Then I used the External option to run a child
script that saved the key field, put a 9999999 in the key field,
then issued New to create a new record and put the original key in
it. Then going back to the parent, I issued SetField() which wrote
over the new record. This sequence was repeated for each child
record of the same parent key.
After each set of child records for the current parent, I issued
another child script that replaced all the 9999999 values with the
saved key.
This is a real mess. It just wouldn't be practical for an
application that is writing lots of child records on a random basis.
