Best way to create related records?

[donwolfkonecny]

The way I create related records is always (goto related field, to portal last row) and start setting, which has obvious disadvantages such as : requires this "messy" portal display someone on a layout or a switch between layouts, but always I have to remember to put this portal and field on some administrative layout just for this purpose. Also, this does not work for IWP. My solution for IWP was to create a record through a nonsensical relationship like linking date to key, then immediately set the key to the desired value, which works with IWP, but still requires the extra relationship and "hackiness".

 

I could sure use an insert function that creates a record in another table with all the values I feed it all in one step. I'm not sure if this already exists or if someone else has figured out a work around without a bogus relationship and without writing to the last row of a portal.

 

Any ideas?

[comment]

I never create records through the last portal row (except by typing manually, that is). In version 8 you are blessed with script variables, which allow you to load the script with all the required data, go to the child table, create a new record, set fields to variables, and come back.

[LaRetta]

Now this is confusing ... the post is in 8.0 but donwolfkonecny indicates vs. 5?? I never use portal rows either (for new record creation). But, even before vs. 7 or 8, a simple jump to other table (or file), create the record then return - all under a Freeze Window always works well. How you pack your lunch (take the information with you) - whether global, script parameter or script/global variable - is the only real difference. smiley_cool

[donwolfkonecny]

I never create records through the last portal row (except by typing manually, that is). In version 8 you are blessed with script variables, which allow you to load the script with all the required data, go to the child table, create a new record, set fields to variables, and come back.

 

I am in 5.5 but migrating to 8.5 and hoping for something more sensical than what we've had.

 

thanks for the hint

I loaded a variable but how do I "go" to a different table that does not yet have records related to the mother table? If I am in the child record, how do I create a record in that table and not the current (mother) table? Do you mean create a script in the other table which is NOT what I want to do.

thanks in advance

[comment]

You go to a different table by going to any layout that belongs to that table. This is assuming your tables are in the same file - otherwise it's another ballgame.

 

BTW, you could have done the same thing in previous versions, using a global field to store the ParentID. Except you needed two scripts, one in each file.

[donwolfkonecny]

You go to a different table by going to any layout that belongs to that table. This is assuming your tables are in the same file - otherwise it's another ballgame.

 

BTW, you could have done the same thing in previous versions, using a global field to store the ParentID. Except you needed two scripts, one in each file.

 

What IS the technical meaning of having tables in the same file. I was excited and thought it might mean that searches in a related table in the same file would be speedy but alas that did not appear to be the case.

 

What are the different technical implications of related tables in the same file or separate? Your answer implies that in one script I can go to another table and use the script variables. That's nice. Are there more differences?

 

Lameass filemaker needs to have more help than a reference file. Like a "what this means for your programming" guide.

[comment]

I don't know what you mean by "technical implications". Certainly, scripts belong to a file, so you can deal with multiple tables in one script.

 

There's a LOT of things to learn (and unlearn) when you switch from 6 to 7.

[LaRetta]

One real benefit to multiple tables over multiple files is that, when you are working in your field definitions, they are all in one file and you can jump from one table's definitions to another. You won't have to open the other file to work in another file's fields. This alone can save a lot of time. smiley-smile