Creating a related record invisibly

[Mandu]

I have a form for recording a contribution from an individual. The Individuals table has a one-to-many relationship with the Contributions table.

When the user has entered the data and clicks "Enter", I want a script to create a new, related Contributions record and fill it in. I know how to do it with portals, but there's no reason to have one here.

Every method I've googled up uses a layout in some way. Is there a way to create a related record without using a layout?

[bruceR]

See my file in this mesage:

http://fmforums.com/forum/showpost.php?post/355447/

[Mandu]

Thanks - it works but I don't understand how.

What causes the "global" field [which isn't global in your example, but I don't suppose it matters] to get plugged with the LineItem's record ID when the record is autovivified?

And why do you set just one field in the new record, commit, and then set the remaining fields? Why not just set all fields and then commit?

[bruceR]

Thanks - it works but I don't understand how.

What causes the "global" field [which isn't global in your example, but I don't suppose it matters] to get plugged with the LineItem's record ID when the record is autovivified?

And why do you set just one field in the new record, commit, and then set the remaining fields? Why not just set all fields and then commit?

Yes, it was supposed to be a global, but as you note, works as a standard field; but then it is possible to run into record locking issues, so it is better to use a global.

That's just how auto-create was designed to work. Match fields on the "other" side of the relation are auto-populated. Allow creation of related records is a great and unique feature.

It has been my experience that set one field, then commit is the most reliable. I have definitely experienced problems with set-many. It also give you the option to error check at that point if you want to be more rigorous in your scripting; did the record get created?

[Mandu]

All makes sense. I've never heard of auto-create, I don't think. This will be very useful. Thanks again.

[swells808]

Now what if you wanted to do this with multiple fields to multiple other tables? To better explain I have an order entry form, after this is filled out the data from different fields (customer name, contact info, etc) needs to be sent out to 8 other tables (each has identical filed names). Do I need to create several global fields that each correspond?

[Søren Dyhr]

needs to be sent out to 8 other tables (each has identical filed names). Do I need to create several global fields that each correspond?

No why not share it (you have not fully grasped the global fields role here apparently) ... although a normalization of the structure seems quite urgent? Take a look at this:

http://www.filemakermagazine.com/blogs/tgantos/using-semantic-structures-in-filemaker-generalization-and-aggregation.html

And in particular this:

http://www.filemakermagazine.com/videos/data-tagging-classification-vs-organization.html

...as a rule of thumb - if the scripting gets lengthy and clunky might the lack of relational approach be the culpit!

--sd

[swells808]

That would be fine except that this has to connect to outside SQL sources and therefore has a very specific structure.

[Søren Dyhr]

Ah ... deus in machina!!! But still would I think one single global is what it takes dispite ESS'ing!

--sd

[bruceR]

That would be fine except that this has to connect to outside SQL sources and therefore has a very specific structure.

So?

No, it does not have to have a very specific structure. You need a global that connects to the primary key of the SQL table.

The same global can point to each of the tables. You just deal with one at a time. Set field TableA::someField; set field TableB::somefield; etc. taking care to clear the global after dealing with all the fields in tableA before moving on to tableB.

[bruceR]

Now what if you wanted to do this with multiple fields to multiple other tables? To better explain I have an order entry form, after this is filled out the data from different fields (customer name, contact info, etc) needs to be sent out to 8 other tables (each has identical filed names). Do I need to create several global fields that each correspond?

Sounds like a design problem. Why are there all these identical tables?

[swells808]

LOL it is a design issue unfortunately not mine. The boss demanded a specific structure. Personally I am making a second version that has all the data in one table and just uses layouts for the requested window information.