Another question regarding a script I've attached. As you can see from the attached picture of the layout- It's an invoice. In the pop up you select a product. A button on the portal row captures the ID as a script parameter. It's the next part that's new to me. What I'm accusomted to seeing in other explanatinos solutions is this:
- Set variables for InvoiceID, ProductID (which the button feeds to the script as a parameter (because you selected a product from the portal)), and any other info you want to take to the join table.
- Go to layout based on join_Invoice_Product
- create new record
- set the record's foreign key's with the InvoiceID and ProductID
However in the Filemaker starter solution,
- they stay on the invoice layout
- have the script navigate to the first field on the portal
- navigate to last portal row (Go to Portal Row [last]
- Set the product ID
- Why do they do it this way? I see that they declare one less variable and don't create a new window / go to another layout, but I don't know the significance of that (performance?)
- Why do they set a variable for both the productid AND the item name? Couldn't they just take the product ID and refresh records? The only reason i can think of is that their method ends in the Quanity field. But couldn't you create new record in a different window, close the window, and navigate to the same field?
It's not that I sense any problem with their method, rather I'd just like to know why they do it and if it's a 'best practice.' Especially since creating new records in join tables seems like something I definitely want to do the right way.
Here's the image of the layout:
One more question regarding Filemaker's invoicing solution. I've attached an image of the script and an image of the relationship diagram (which also applies to the above examples). On the pop up shown above, there's a script attached to the New Product button (see attached image).
For the most part- their model accords with what I've learned elsewhere. To create new products from the invoice layout (product is 2 steps away across a join table), a new product to is related to a Global Variable foreign key (which I'll refer to as MatchID (Global)) in the invoice table (with allow creation of records in the product side). Then, on the pop up shown above, there's a script attached to the button that does some prep work and moves the slider to the new product slide.
It's the first step of the script I don't understand. The way I've seen it elsewhere, the 'prep work' is making sure the MatchID (Global) is cleared so that when you enter new product info (name, manufacturer, etc...) it creates a new record. Instead of setting the MatchID (Global) to empty (""), there's this: (for ease of reading I've made the the MatchID (Global) red and the MatchID of the the new products Table Occurrence blue.
Set Field [invoices::PRODUCT ID MATCH FIELD; GetNextSerialValue ( Get ( FileNAME ) ; GetFieldName ( All Products | Popover::PRODUCT ID MATCH FIELD) )
It's like their setting the MatchID (Global) to the serial number before it's been generated. If so, why? If not- what are they doing?
If this is the correct way to do it I'm at a loss as I've already set up with UUIDs.
And here's the relationship diagram (I hope I'm correct in thinking it's only one image per post).
IT looks like this script is anticipating the ID to be generated automatically when the next new product record is generated in Products. Presumably, this then allows the user to enter data for the new product in a slider inside that popover and that successfully creates a new product record.
That's clever, but it can produce problems if the file is shared over the network and two different users run this script at the same time and thus get the same value returned.
It's also unnecessary unless FileMaker 13 has changed a basic behavior. If "allow creation of records via this relationship" where enabled for "New Product | Popover", the script could just clear the Match field in Invoices and entering data into one of the fields from New Product | Popover will create a new record in products that links automatically in Invoices by copying over the new record's ID. That avoids any issues that might occur when hosting the file over a network.
We usually use this field in the opposite direction--using allow creation to enter the layout record's match field value(s) into the fields of the newly created records, but the reverse also works.
Thanks Phil. The method you outline was my plan (here's a clear tutorial for anyone interested: https://www.youtube.com/watch?v=5FS-ETvvFbQ starting around 14:45). I'm surprised to see that not only is their way not necessary, bu your point about duplicate serial numbers makes it seem downright dangerous. Perhaps their scripts aren't so great to learn from? Unless anyone has support to offer for their method for creating new records in child tables I think I'll go with the method I've seen outlined elsewhere- capturing the 2 primary keys and creating the record in a new layout (as opposed to having the script navigate to the last row of the portal).
The starter solutions are not created by super programmers that never create mistakes. I've pointed out flaws in them myself. But they are created by experienced knowledgeable folks and do serve as useful examples of how you might go about designing things. I've learned a number of useful tricks from them myself.
capturing the 2 primary keys and creating the record in a new layout
Is a method that I've used frequently, but it's not the method that I outlined here.
My bad- I thought the method you outlined was for creating new records in a distant table (ie on the far side of a join table) and was addressed to my 3rd question. My point about "capturing the 2 primary keys and creating the record in a new layout" was in reference my 2nd post and describes the method I've learned for creating a new record in the actual join table after capturing the product's primary key from a button's script parameter.
This is (as best I can tell) how the starter solution does it in order to have a nice searchable list as opposed to a colossal dropdown (presuming, ultimately, 1000's of records) list in a portal row. This part I get and works perfectly for me. However, in the starter solution (again, as best I can tell)- despite having already 'gotten' the product primaryID, they also get the corresponding product name and stay on the invoice layout by navigating to the portal row instead of storing the invoices id in a variable and creating a new record in a new off screen layout (so in this case they do take advantage of the 'allow creation' property).
I just wanted to be sure that this wasn't an inherently superior method before I did all the work of making join tables work. I was especially concerned cause I honestly couldn't tell any difference between the two methods. One method (new layout) is the one I've seen in literally every tutorial. The other method I've never seen- but was crafted by the actual people at Filemaker. I want to use the best possible method for this very fundamental procedure.
I didn't mean to criticize the filemaker devs. It's tough to find out about some of the more advanced stuff that should be in scripts (or at least advanced to me- like 'allow user abort" and 'flush cached join results'). Their scripts are replete with these things. To know when, where, and how to use that stuff- it's hard to know whose example to follow. Many of the issues I'm guessing they address (networking issues), I've yet to learn about. I can't learn everything in advance- my hope is that if I follow 'best practices' I won't find myself in a bad place when I do learn about them.