New to FM - trying to understand relationships - and layouts - creating new record in one table from layout of related table

[dawg]

Hi…

 

I'm relatively new to FM so please forgive the level of this question.

 

I have created four tables as follows:

 

Customer

JobSite

Equipment

Service

 

Each Customer can have many JobSites, each JobSite can have many pieces of Equipment, and each JobSite can have many Services.

 

I've tried to create a button that creates a new JobSite record from the Customer layout. I created a script and attached the script to the button on the Customers layout. However, I'm clearly "not getting it".

 

It would be much appreciated if someone could take a look to see what I've done wrong. Seems I can't upload a 

.fmp12 file so here's the script:

 

Set Variable [$SetJobSiteID; Value:Customers::CustomerID]

Go to Layout ["Job_Site" (Job_Site)]

New Record/Request

Set Field [Job_Site::Customer_ID]

 

Also attached the relationships diagram.

 

Thanks.

[dawg]

duh!

 

I just figured it out. Sorry. I guess I had to write it out to figure it out. I didn't specify the $SetJobSiteID as the result in Set Field.

 

I'm sure I'll have more questions down the road though ;-)

[eos]

Set Variable [$SetJobSiteID; Value:Customers::CustomerID]

Go to Layout ["Job_Site" (Job_Site)]

New Record/Request

Set Field [Job_Site::Customer_ID]

 

Set Field has two parameters: The field name, and the result; you've specified the field to set, but not the result expression (which in this case would be the variable you've set before).

Set Field [ Job_Site::Customer_ID ; $SetJobSiteID ]

btw, you may want to add the following steps to your script, 

Commit Record/Request
Go to Layout [ original layout ]

EDIT: … If this is a record intended to be edited within a portal row …

[comment]

btw, you may want to add the following steps to your script:

Commit Record/Request
Go to Layout [ original layout ]

 

 

I am puzzled why you would want to do that, instead of (I presume) letting the user fill out the details of the newly created job site, perhaps even change their mind and revert the record before it's committed.

 

 

---

BTW, going to another layout will commit the record implicitly - so the Commit Records step would not be really required.

[eos]

I am puzzled why you would want to do that, instead of (I presume) letting the user fill out the details of the newly created job site, perhaps even change their mind and revert the record before it's committed.

 

I assumed (…) creating a related record, going back and editing it in a portal.

[comment]

[shrug] If so, why not create the record in the portal to begin with?

[LaRetta]

It has been my experience that creating records in portals can be subject to break if another portal is added to the layout.  Or what if the portal is actually removed; normally the script should still be capable of creating the new records without portal and what if later you forget and change the sort on the portal etc.   So if you do it, at least object name the portal or a field within to help protect from break but I feel it is still more risky practice.  

 

I usually go to another layout to create a new record even if I return and work in the portal.  

[LaRetta]

There is also the issue of the empty row accidentally creating blank records if 'allow creation' were on.  Usually when I don't see things exactly as you do, Michael, I learn more by asking if you'll explain a bit more of your thinking.  

[comment]

Ahm... I meant why have a script at all, if you will be working in a portal? Or, if you already are in the child table, why return to the portal - and, I should add, navigate to the corresponding row?

 

As a rule of thumb, I won't let users work in the portal (create OR edit), unless they are trained (i.e. their primary occupation is to work the solution).

[comment]

One more thing: validation prevents blank records (and script triggers prevent validation errors...).