2 of 2 people found this helpful
Script Steps that begin with the word "insert..."
all require the target field to be physically present somewhere on the layout.
And all but a few can be very frequently replaced with set field or set variable, which is probably why you are forgetting which require an actual field on the layout.
Other interface specific steps have the same requirement, but it wouldn't make sense to put them off the edge of the layout as far as I can tell such as:
Go to Field
Go to next field
Go to Object
2 of 2 people found this helpful
When using transactional record creation via a portal and you don't want the portal visible or accessible to the user.
Thanks philmfdjunk, this is so rarely needed on the stuff I've been doing I had forgot something so simple.
Thanks Mike for the cool tip, I'm going to try that approach some time instead of jumping to a different layout and back, could come in handy and make the script less complicated when added related records the you don't really care for the user to see.
I always try to avoid using a portal as a way for a script to create or modify related data. There are other options that avoid the scripted portal interaction--which can be vulnerable to being broken by future layout changes.
There are ways to use a relationship to create new related records, for example, that require neither changing layouts nor interacting with a portal row.
Yes, you can use the “magic key” method. But that isn’t transactional.
Can you explain by what you mean by "transactional"?
This touches on a presentation that I'm doing in October so this could be useful info for me.
When you create records through a portal, both the parent record and all associated related records are locked. If something goes wrong with the routine, you revert the record, and boom. Back where you started.
IOW, using transactions prevents a partially-complete operation. If you’re curious, there are plenty of discussions about it over on Todd Geist’s web site (geistinteractive.com). He was one of the pioneers.
Thanks, that's the clue in that I needed.
Part of my presentation is on avoiding inherently brittle script steps, but the qualifier that goes with that is to go ahead and use them when there is a good reason to do so and that would, potentially, qualify as such a reason.
3 of 3 people found this helpful
After doing some tests, I went to the Geist site and read up on transactions just to make sure that I'm not missing something. What I'm finding is that I can use magicKey to create multiple related records and as long as I do nothing to commit records on the parent record, I can use Revert Record and revert all the newly added related records--just as can be done via entering data via script into the last row of the portal. And it's interesting that you mentioned this particular source since Todd is one of the originators of "selector-connector" a data model well suited to using magicKey to create related records.
I even opened two windows to the same layout and record and tried triggering locked record errors and couldn't find any difference in behavior after using either method to create several new related records. Neither method explicitly locked the parent record. (I use a script with a global field in a custom dialog to gather input for the new related record before either using set field via the magicKey relationship or set field into the last portal row to create a related record.)
Did I miss something?
Just to be sure we mean the same thing, "MagicKey" is a technique where you link a global field in the parent table to the primary key of the child table with "allow creation" enabled. Then, set field can be used to set data to the child table via this relationship as long as the global field is empty. A new related record will be created and the ID of the child record will be copied back to the global field.
The previously stated positive features for this method are two fold:
- You avoid tripping any script triggers due to changing focus--as can happen both by setting data to the last row of a portal and by changing layouts/windows to create a record on a layout based on the child table.
- A script using the method does not require that any specific layout objects (such as a portal) be present nor have the focus in order to successfully create records.
I don't know exactly what you did, Phil, but on my machine, creating a record through a portal definitely locks the parent record. I didn't use a Custom Dialog to gather the data; I simply went to the last row of the portal, entered data, and tabbed to the next (new) blank row. The same record in another window throws the standard "being modified in another window" error.
Selector-Connector explicitly uses a table with no non-global fields to prevent record lock. I have experienced the locking behavior myself in a production environment (which was rather embarrassing) because a single-record table locked down when Magic Key was employed. The "no global fields" rule prevents that.
So I'd love to see your sample file where the records aren't locking.
I think Phil is saying with Magic Key, you don't need a portal, just the related fields (blank until filled, of course). But I'll let him answer.
Um, the "non viewable part of a layout"? Sure, I do this on admin layouts that contain summary fields. If you want the summaries evaluated every time you perform a find, put them in the viewable part. Otherwise, place them off to the side.
do summary fields NOT "evaluate" when they are in the 'non-viewable' part of the layout? what about calculation fields?
- too early to test for myself...
When a tree falls in the woods, ...
Does it make a noise?
I tested a table with one data field (and a million records), one number and two summaries based on the number. To see the effects, resize the window to show the summary fields. Also, try to omit a single record with and without the summary fields showing.
In my case, resizing the window to show the summary fields will cause FM (and Windows) to freeze until the summaries have been evaluated.
temp_SumTest.fmp12.zip 3.7 MB