relate or go to layout

[Charity]

In general do you all like to move around in layouts during a script or do you like to stay in one place?

For instance, do you create a relationship with allow creations on and set a field through the relationship or do you all like to grab variable and go to the other layout and create the record and then back? It does not seem so important when you are talking about one record but when you must loop through a bunch of records and, if there is no related record, create one, then what?

So I don't mean during data entry. No user involved in this. Let us say that I have script which needs to regularly create a record and since I am busy with my script, I would rather not leave and go somewhere else while I am inside a loop but there is not a relationship. So do I create a relations with creations on or do I jump?

Which is safest?

Which is quickest?

Which do most of you use since you all have the experience?

I keep reading both sides of this discussion all through posts in various ways:

Why create relationships when you can go there and back easily?

Why go there and back if you can create a relationship?

Thank you all for any input on this seemingly complex subject. Oh and I realize it is not truly about relationships but scripts forum did not seem to fit perfectly either.

[comment]

Creating the first related record via a relationship is easy; it gets more complicated when you need the second and the third... Over the years, people (including yours truly) have come up with various "smart relationships" to enable repeated creation of new records. However, once script variables became available, I prefer loading them and going to the child layout. Less clutter in the RG is always a plus, IMHO.

[Charity]

That sure helps. Thank you for replying. I consider like this:

1) It must take time to go to the other layout and back.

2) Creating through relations must take a bit longer to commit or make the record real than if creating a record in its own table. (no idea on this. it is a guess)

3) Writing to variable must also take some time so needs to be included in consideration (but I read it is still faster than set field).

4) creating in graph is last thing I want to do (I do not do well in relationships) unless the speed difference justifies it (no idea what I would consider 'justified' ; I'm just sayin)

5) setting the ID would take place with allow creations automatically but would need to happen with Set Field if we go to the layout (so it needs New Record and Set Field). Add another .00000001 seconds to time it takes if going to layout?

Maybe I should write all the records' data to the variables before I go so I only go once. Would that not be the best of all combinations? Only one layout switch, create all records in their own table, maybe opening a record request although that might not help speed it up here, do work then jump back. Or is that what you mean anyway?

Has anyone timed these things? I would love to read about it. I think all these pieces will be important, like orchestrating a symphony. Right now I'm on chopsticks. BTW, I can say what not to do. Do not open a new window, go to layout create record then close window looping if you have not started with a freeze window. If you run it on 100,000 records you will go into a trance. :shocked:

[comment]

If you regularly need to create 100,000 related records, then yes - you would time the different methods. But then we would not be speaking in general, and I would also ask why is this necessary.

[Charity]

You are correct. I was speaking in general to understand generally but also for a current issue and it is not 100,000, it is like 20-50. The window example was my attempt at humor saying what did not work in a different situation - my first script using multiple related looping by opening window instead of moving. System had to be forced down.

Variables have tiny feet and are very easy to use even for me so your suggestion is the best answer generally and maybe not generally. I had better get busy practicing arrays and things to get very good at them! Again, thank you, Comment.

[Echo33029]

One of the techniques I use to avoid having to switch layouts is to allow FM to create the record based on a relation As Comment said, the first related record is easy to create, Subsequent ones require a different approach. One way is to create a global field in the parent table and create a relation between that and a new TO of the target child table (remember to set allow creation of records on the child side of this relation). Once that relation is created, set the global field to empty, and then use a regular Set Field step using the new relationship for the target field. This will automatically create the record and you can then populate all of the other fields. Once you are finished with that record, then clear the global for the next loop iteration and do it over again.

This technique is also a good way to avoid committing the records until you are finished your processing, allowing you the opportunity to use the Revert script step if you detect some error during processing (remember that you will automatically commit when you change layouts back and forth in your script).

Listen to the MagicKey discussion at the following link: http://traffic.libsyn.com/fmsuccesstips/FM_Success_Tips_DEVCON2011b.mp3

Leo

[Charity]

Hello Leo,

Thank you for adding such a great link. I do no understand the logic on how ID flows backwards to Parent. Can anyone explain this strange thing? I thought in FM we needed an index on the side for data to go to it. I probably phrased that improperly but I mean it must be 'child-able'. Is it because globals are kinda stored anyway in their own weird way?

This suggests that if a child has a parent but no parent at the moment the child is born that the child creates the parent relationship to the new parent attempting to adopt it even without allow creations on the parent side. I think it is the strangest thing I have ever read about in FileMaker yet.

Does FM know about it and do they say they plan to keep it that way? I would hate to use it and then find out they thought it was a bug and fixed it and then my stuff would break. Since it involves creating records (or not), a break in this would be quite ugly.

[Charity]

I must have been daft earlier. This idea is from Kevin Frank so it can not be bad or dangerous and I am sure it has been checked out. It was just unsettling. It is like finding a place on earth where gravity goes up.

[Echo33029]

Basically in FM when you use a Set Field to set a field in a child table, and the parent key field is empty, FM creates the child record and assigns the child record matching field's value to the parent key. If you follow the standard recommended practice of always giving every table a unique autoenter ID key field, and using that field as the matching field on the child side, a new unique record is created and its ID will be assigned to the parent MagicKey field, thus creating a unique relationship.

The parent side field does not have to be a global. Any standard field will work.