Commit Records/Requests

[LaRetta]

Hi everyone,

Because of a prior post, which I almost (out of excitement and curiosity) hijacked, I wish for feedback and enlightenment on this subject. In this post , Soren said ...

What about the sprinkling of Commit steps after each Set Field??

My response (moved here to be polite to those on the other thread), was going to be:

Soren, my goodness ... you almost make it sound like you're not quite sure exactly WHERE to put Commits!! The word 'sprinkling' suggests a hit-or-miss pattern. I realize you probably said it in that way because you have no idea what the scripts involve, but I couldn't help but jump in. Am I being condescending? Nope. Just curious. Because *I* feel uncertain almost daily on where a Commit should be used to 1) commit the record to establish a relationship, 2) release possession in multi-user and 3) any other stuff ? (smile).

--- I'm back live ---

I have read many posts on Commit Records. Most responses use phrases such as, "You can try adding a Commit" or "Maybe a Commit is needed." Now that we've all been using 7 for a longer period, I'm wondering if your understandings have deepened and you can share them. I need to get inside of it. I try to visualize the cursor while scripting. Remembering to 'pull my cursor out of a field' when opening a new window is a prime example. I would just like to gather everyone's thoughts, experiences and suggestions on good use of this 'improved' Exit Record/Request script-step (mostly but not necessarily in multi-user). Because it never fails ... I'll have a very pretty script (if I say so myself) and it will break at strange times because I don't PROPERLY understand EXACTLY when Commit should be used.

See? Short post. Right?

LaRetta

[SlimJim]

1) commit the record to establish a relationship,

My files are all essentially single-user so if my comment doesn't apply then ignore it. I'm not convinced that committment is necessary to establish a relationship. For example I have an invoice form and the first piece of data is the Quote number from the quotation we made for the job. As soon as this is entered the company name and address and all the data associated with the quote is dropped into the form, There is also a list of previous invoices on the quote and even a portal with all their previous jobs. I am fairly sure that at this moment the record is not committed. If I click on a blank bit of layout I get the usual Save/Don't Save dialog. So all of these relationships are established by the input of one field and before the commitment of the recod.

Logic would suggest that this can't happen - until the record is committed it doesn't exist, but obviously it does exist. Perhaps this explains some of the "ghost" records behaviour that people on these forums have reported.

[LaRetta]

I'm not convinced that committment is necessary to establish a relationship.

Hi SlimJim, thanks for responding.

Sometimes yes, sometimes no. There is more to it than that ... try this very simple demo on for size. This is User handled but could very well be one of our scripts after a Set Field[] or other cursor script-step!! You see?

I'm going to the Blackberry Jam festival today and actually can't work on this again until mid-week. But I will present several scenarios I've been collecting that might surprise some people. And my deepest hope is that you all present even more examples of your findings right back, debunk some of mine in return, and teach me a great deal. That darned cursor location and the current record commit state is critical to proper function. And this is only a very small part of the picture; we haven't gotten into multiple windows of the same set/record yet nor multi-user. And record possession is CRITICAL or the remaining Set Fields won't SET so this is a two-sided subject ... sorta like "know when to hold 'em and know when to fold 'em"!

I want to get my understanding of this down to a set of principles so that, when scripting, I can just rock and roll on it instead of guessing and leaving a critical Commit off OR adding them when unnecessary OR not claiming a record when my script needs to set fields. I want to VISUALIZE the PRINCIPLES while I script. I don't want script-steps to misfire because I guessed wrong. Yesterday in 3 forums, I read the phrase "maybe a commit would help" 4 times!!! Maybe? Not good enough...

Catch ya later!

LaRetta

commit.zip

[SlimJim]

Yes this demonstrates the point that it is sometimes yes and sometimes no. The match field calc that you used is a bit unusual but that is not the point. The point is how can you predict when the record needs a commit and when it doesn't? On the basis of your example it seems to be saying for safety commit after every field change but that is really OTT and hardly necessary in simple situations such as the one I was describing. I suspect this will be my last contribution to this thread but I will be watching you.

[LaRetta]

Many times, relationships are based upon unstored calculations because they come from Get() functions or related data ... xor are dependent upon field data which is used within an unstored calculation. This is point #1 on my list. I hope I get a lot of feedback before I finalize my Principles: Commit doc.

Put cursor in field to gain posession ... do your work ... remove cursor to release for multi-user and (in some cases) establish a relationship. As careful as I have been, I have a confession ... a few weeks back, I found a script which missed setting some fields occasionally because during script execution cursor left a field and it became locked by a user. Thank God for our Audit Track or I wouldn't have figured it out. And unless one tests after every Set Field[], MAINTAINS possession or traps at the appropriate time, the dangers are always present. Error Trapping only protects so much. And sometimes (if you've left your cursor in a field) it can bite you much later in the script (or a sub-script or a different script) when you are depending upon a Commit to continue in a related table, another layout, or another window. So much to learn ... so little time.

LaRetta

[Søren Dyhr]

Nope. Just curious. Because *I* feel uncertain almost daily on where a Commit should be used

So do I - You should know that I work in a team, where I'm not the expert on web-publishing, and as it is do usually get either a thumbs up or down to the stuff I add to a solution, which doesn't make me wonder why, but instead deploy the next approach of the 3-4 ways I've thought of for the particular solution ...hoping that interpolation will occur eventually.

I do always seek to keep scripting down to a minimum, believing that extensive scripting is an error in the relational structure. But one of my thought once were... why isn't it a checkbox in the Set Field[ step, why an independent step.

Maybe is the cursor approach a fine way to grasp the matter ...I'll see if it makes sense in this question I raised a week ago:

http://fmforums.com/forum/showtopic.php?tid/168313/

But LaRetta what a good thread you've started here!!!!!!

--sd

[geod]

:D The Filemaker Technology Brief pdf, titled "Upgrading to FileMaker 7: Migration Foundations and Methodologies" has a good explanation of the new record ownership rules and contrasts them to earlier versions.

For instance in 7 merely putting the cursor in a field does NOT open that record for ownership, it is not opened until you begin to modify it or change the value.

Anyway a good read.

geod

[LaRetta]

I read that pdf too, Graham. I must have been zombie tired at the time because I remember nothing about THAT!! Of course we weren't networked then and web was just a spark in my eye and record possession and cursor placement remained in my "To Be Understood" folder from months prior. Thank you, I have some reading to do.

I feel a ton of speculations shifting or hitting the floor as we speak (and from last night). Online use (very weak in my knowledge base) appears to add interesting twists as well. I may not get this down to a fine-tuned theory (and rigidity is not my goal) - the human mind still outplays a super-computer chess game - but a checklist factoring in variables is quite possible! I envision a logic branch. :D

[Fenton]

Yep, LaRetta, you should read it again. The charts in the PDF article (by Ilyse Kazar) lay it out pretty clearly. Just putting your cursor in a field does NOT lock the record as in 6, so any script which uses that to claim ownership must be changed.

You can use an explicit "Open Record" step instead (new to 7). Try it. Put a button that just does the Open Record step. Create a new window of your layout. Click the button. Then try to edit in the other window.

The above still produces error 301, when Error Capture is On, so you can just use Open Record in your scripts instead of Go to Field [] (as far as I can tell).

[LaRetta]

OMG!! I have some cleanup to do!!

Well, we can scratch record possession from the above considerations.

Wait. I refuse to be hasty [color:red]for once. I just need to re-work my theories, that's all. Thank you, Fenton!!

[Søren Dyhr]

But Fenton and Graham, would you by it say that a statement like this:

You may need to add a

[Fenton]

I'm no expert on IWP either. I agree with your general feeling (hey, I'm from California, we're allowed to talk like that -) 1. You need to know when to Commit Records, and 2. You don't need to Commit after every Set Field.

You only need to Commit Records once after numerous Set Fields in a table. You usually only need to Commit Records once after Set Fields in many records, say at the end of a Loop. Because going from one record to another commits the previous record; only 1 record is open at a time. Commit Records is for that window; the record could still be open in another window.

A Commit Records step on a record of a Parent table will also commit the records in its portal, same as clicking outside a portal. So if that's what your script is doing, setting fields on "portal" records, then you can just Commit Records once at the end (and maybe once at the beginning, to get out of all fields).

UNLESS within the operation you are setting a field, then immediately using it in a relationship. In that case you should Commit Records after the Set Field, before using the relationship.

One time you do NOT want to Commit Records right at the beginning of a script is if it is for a button in a portal. Because it will pull you out of the portal, and will then only address the 1st row.

[geod]

:D From the the FileMaker Program Help File:

"When possible, the Set Field script step makes the record active and leaves it active until the record is exited or committed. Scripts that use a series of Set Field script steps should group these steps together if possible, so that subsequent Set Field script steps can act on the record without having to lock the record, download and upload data, index the field, and so on, after each individual Set Field script step. These functions and record level validation are performed after the record has been exited or committed."

geod

Edited July 31, 2005 by Guest

[Søren Dyhr]

You only need to Commit Records once after numerous Set Fields in a table. You usually only need to Commit Records once after Set Fields in many records, say at the end of a Loop. Because going from one record to another commits the previous record; only 1 record is open at a time. Commit Records is for that window; the record could still be open in another window.

But scripted Replaces then??? It will leave each previous record open won't they???

--sd

[comment]

Is it possible for a single user/window to have more than one record/request open? Maybe two, in case of editing a portal record, but more than that?

[Fenton]

From p. 82 of Ilyse Kazar's article, chart of actions, whether they commit a record or not:

1. "...run a script whose action causes a change of records - Commits the record (and any related records that have been opened"

2. "Move cursor focus from one portal row to another - All portal-row records that are edited remain open until the parent record is explicitly committed."

My take on this is that if your script is just moving from portal row to portal row, the related records remain open. If however your script is going to the related records, on another layout, and processing them there, they are committed each as you go, the last explicitly committed with a script step.

It's a little ambiguous perhaps, if you have a portal, but script by going to the related table. I almost never run scripts using portal rows. I always go to the related table. When I run such a script using Debug mode, I see the field gain focus, the Set Field (or whatever) take effect, then the field loses focus on that record, but gains it on the next record; all lookups etc. happen as expected between records in the Loop.

I do not see the need to commit within the Loop, unless using that data with a relationship (I might also commit there if the data was then used in a complex calculation). I don't know the definitive answer, just what I think and what works for me.

I'm talking about light and medium duty here, not "super-duper high volume explicitly Open Record and trap for errors" operations. I would imagine in that case you might as well commit after each, though I'm fairly sure an explicit Open Record commits all other records of that layout-window anyway.

[comment]

That (point 2 above) is interesting - and frightening. So one user can lock an entire table by systematically modifying portal records one by one? LaRetta sure has opened a can of worms...

I am convinced that going to the related table must be different. After all, you're not even on the layout with the portal anymore.

[LaRetta]

My Principles: Commit.doc is a mess. As I am reworking this, can someone clarify one point? To me, a record is locked (possessed) or it isn't. You all use words Active and Open. Can you clarify your meaning so that, as I read your posts I understand it more? A little thing, but I keep getting lost on it.

I *think* Active is locked (by us or by anyone else?) and Open is available for possession (by us or anyone else?). Right? I can't visualize which is which anymore. :crazy:

[Fenton]

I agree with comment that point 2 is a little unnerving. It kind of makes sense though, according to the new option to only commit the record after you say so, if you've unchecked "Save record changes automatically" (which I always leave checked, but which has some more relevance with IWP, where changes have to be explicitly committed).

In other words, if you're changing data in portal rows, whether manually or scripted (and FileMaker doesn't really distinguish), then all the portal records that are edited (not all the records, just those changed) remain open until you commit their parent record (along with any changes you made in the parent fields. Otherwise FileMaker could not revert back if someone decided to not commit the record. It would ruin functionality of the interface for that feature if portals were not treated as part of the parent record.

I almost never script inside of portals, so I haven't run into that exact situation. I've not had many problems knowing when to commit, though I often have to think about it a bit; it is certainly an area that could stand a bit more careful testing, to establish exactly what you need to do and when.

LaRetta, there are different words because there are different people speaking. It was the FileMaker Help file that used the terms "active", "locked" and "exited". The actual terms used in FileMaker are "Open Record" and "Commit Record". After "Open Record", it is explicitly "locked."

"Active" could be a record with a cursor in it; which may or may not be "open" or "locked" in 7. I'm not exactly sure what they meant. I think technical writers for software documentation go to a special school, like law school. They are always correct and concise, but you sometimes don't know exactly what they mean.

[Vaughan]

This could be an amazing opportunity!

Imagine having a critical process that works on a found set of records; if one record in the set is locked then the process has to be cancelled or reversed. Doing this record-by-record is a real challenge. Instead, display the found set in a portal, loop through the rows to open all records by editing a trivial field, then if they are all opened without error, loop through again to perform the real process. Commit the master record to complete the process.

Unfortunately I hate looping through portal rows, but I could learn to live with it...

Edited August 1, 2005 by Guest

[Søren Dyhr]

That (point 2 above) is interesting - and frightening. So one user can lock an entire table by systematically modifying portal records one by one? LaRetta sure has opened a can of worms...

Indeed she has, but I'm very glad she did because she's so much better to raise threads than me. My thread...

http://www.fmforums.com/forum/showtopic.php?tid/168313/post/169518/hl//#169518

didn't recieve much traffic, but is actually quite related. My discovery this week is that unless you open the parent record before going to related table and batch create records under IWP, will the java engine try to catch up with your addition of records ...and unfotunatley will it do it wrong like two people attempting to put a door back on it's hinges ...both persons are overcompensating for the others movements.

In IWP is Go To Portal Row Grayed out, so doing an addition of records in the related table via scriptparameters seems an obvious way to do it, instead of letting the script tabs it's way thru to the portal rows and Insert Calulated Result'ing ...Well it can be done but the calc to sniff in which field the cursor is located at present and then plucking the correct parameter in the parameter string is bysantine.

--sd

[Fenton]

Yes, you're right. It is a feature. And I don't think you have to edit a record to open it, just use the explicit Open Record step, which I imagine works on a portal row (though I've not seen such as an example). Or does it only apply to the main record?

Edited August 1, 2005 by Guest
Equivocating, by lawyer's advice

[Søren Dyhr]

then if they are all opened without error, loop through again to perform the real process.

Good catch!! Will they change status if you make a GTRR just after the first loop?? If so would it be a good way to make scripted replaces behave!

--sd

Edited August 1, 2005 by Guest

[Søren Dyhr]

And I don't think you have to edit a record to open it, just use the explicit Open Record step

This seems a little counter intuitive to me, what is actually the focus of the "Open" step, the parent record or the cursor chosen portalrow. I would say that a safer bet would be to grap the fields value and set it to itself by Insert Calculated Result[

--sd

[comment]

Imagine having a critical process that works on a found set of records; if one record in the set is locked then the process has to be cancelled or reversed. Doing this record-by-record is a real challenge. Instead, display the found set in a portal, loop through the rows to open all records by editing a trivial field, then if they are all opened without error, loop through again to perform the real process. Commit the master record to complete the process.

Unfortunately I hate looping through portal rows, but I could learn to live with it...

I also hate looping through portal rows. I would prefer something like this:

...

Go to Related Record

Loop

# ACTION

If [ Get ( LastError ) ]

Set Field [ Parent::gLockedIDs; Parent::gLockedIDs & Child::ChildID &

[Søren Dyhr]

I would prefer something like this

But it seems the scripting in the child table is opening and closing for each Go To next Record[Exit After Last] ...this is why I talk of scripted Replaces.

--sd

[comment]

A scripted Replace will generate a single error when one or more of the records are locked. There will be no trail of which records were successfully modified.

[Søren Dyhr]

A scripted Replace will generate a single error when one or more of the records are locked. There will be no trail of which records were successfully modified.

Would it??? If this trick is possible, Vaughans way - have just made a found set of possessed ...hasn't it??? Well I can't tell....

Instead, display the found set in a portal, loop through the rows to open all records by editing a trivial field, then if they are all opened without error, loop through again to perform the real process.

--sd

[comment]

Vaughans way - have just made a found set of possessed ...hasn't it?

I don't think so. Unless I am missing something, he is opening (or trying to open) portal records one by one, "then if they are all opened without error, loop through again to perform the real process".

I presume that if he cannot get all of them to open, the process will abort and perhaps try later.

How is this connected to Replace or found set?

[Søren Dyhr]

How is this connected to Replace or found set?

By a GTRR(SO) ...Ilyse says that the parent record remains open until committed take a look at p. 84 in the .pdf ...the missing bit is that if all shown in the portal are open correctly what will they be after GTRR'ing ...still open??? The only thing she talks about is when the file isn't fmrobotted into the same file.

--sd

[comment]

I believe that if GTRR takes place in the SAME WINDOW, the parent record and all portal records will be released. If you open a NEW WINDOW, the old window (now in background) will continue to keep any opened records locked. IOW, it's a window issue, not a parent-child issue.

Now, I think the answer to LaRetta's original question is to be found on page 84 of the same document:

"... consider whether you might need to add a Commit Record command to make the change visible to other guests, or to simply release the record lock."

which to me means: if you're not doing anything else to release the record (such as go to another record, etc.), release it by adding an explicit Commit Record step.