what makes a commit?

[rob]

Not sure where to put this

Sometimes I put a commit just because I do not know when it is not needed.  Example, if I create a related record while on parent record by just using set field through to the child table and then I switch parent records, can I safely assume it has committed the child also?  If I switch layouts to a different table, is the current parent committed automatically?  Are there are guidelines to help me understand it?  Maybe it does not hurt to commit just to be safe but I really want to understand it and not commit needlessly.  thank you.  btw, I searched for commit and was overwhelmed and most of it did not fit my request.  If there are links which discuss it specifically I would be grateful.

[Wim Decorte]

There is some danger in relying on implicit commits... if you do the commit yourself then you can trap for and handle errors right there.  Obviously you do not want to commit where none is required but basically any place where you create new records or modifying existing ones you could think about doing a commit and error handling

Every time you commit you are generating traffic between the client and the server, so one important concept is how you can do multiple record creation and multiple edits and only doing one commit when you are done (look up "transactions" on modularfilemaker.org)

[Kris M]

In the absence of any script triggers that could intercept and prevent it commit happens:

http://www.filemaker.com/help/12/fmp/html/add_view_data.4.23.html

[comment]

17 hours ago, Kris M said:

In the absence of any script triggers that could intercept and prevent it commit happens:

http://www.filemaker.com/help/12/fmp/html/add_view_data.4.23.html

That's not a complete list - for example, closing the window is not mentioned. You will find a comprehensive listing in Filemaker's "Migration Foundations and Methodologies" white paper.

[Kris M]

Thanks for the heads up comment

[rob]

I have not responded because as I test and study it I see that it is also as important that I understand what actions take possession of a record.  I have a few questions lined up but as I test I may solve them myself.  Example, I had read that scrolling a portal opens a record but it must have been an old thread because it no longer does according to what I am reading and what I have tested.

Just so you know I appreciate all your responses a lot.

One thing which currently struggles me is that a global field does not open a record EVEN IF TYPED INTO but if a regular field references the global and the regular field is auto-entry replace and I change the global value then that record might be opened but this is at present conjecture on my part because my results are not consistent if on server.  I wanted to respond so you do not think I blew off your suggestions.  It is just taking time.  I am slow at this stuff.

Edited January 22, 2016 by rob
ADDED portion in all caps

[comment]

1 hour ago, rob said:

I see that it is also as important that I understand what actions take possession of a record.

Indeed. Let me recommend once again Filemaker's "Migration Foundations and Methodologies" white paper. Go to page 73 and read “Record Ownership” in Converted Solutions: Opening and Committing Records by Ilyse Kazar,

[rob]

Hello Comment

this is precisely what I read that shocked me and has made me regroup my question from committing only to both opening and committing.  I do not think I will ever look at records the same way again.  Thank you for that recommendation.  It blew me away.

ps I am studying that document until I know it thoroughly and everything else I can read.  Everything.  The more I know about Filemaker the more confused I become and the more I need to study it even more and it is a never ending spiral.

One phrase that still puzzles me is this:  If there are uncommited records in the window that are affected by the operation, these changes will be made using the windows transaction and remain uncommited until you choose to commit the changes following the completion of the operation.

Does this mean that I can use a new window or Open record request and open a found set of records, locking them all even if I have not made changes to them?  What does 'windows transaction' mean?  Otherwise I am working through it okay but just a bit slowly.

Never mind about multiple open records in a found set.  I had meant to study this and figure out myself.  But 'windows transactions' still has me confused so if you have a moment, I could use some clarification.  

Funny that I had been staring at page 74 when you posted.

Maybe only multiple found records can be opened if Replace Field Contents or relookup.  I'm still confused on some of that.

Edited January 22, 2016 by rob

[comment]

1 hour ago, rob said:

One phrase that still puzzles me is this:  If there are uncommited records in the window that are affected by the operation, these changes will be made using the windows transaction and remain uncommited until you choose to commit the changes following the completion of the operation.

Where is this quote taken from?

[rob]

It is in the link presented by Kris M down in Notes, 3rd bullet point.  Maybe it only applies to version 10.  and only to Replace field contents or relookups.  The phrase 'window transaction' threw me.  And also multiple uncommitted records.  Sorry I forgot to provide the source and I also took it out of context I think.  The paragraph just was not very clear but that is just me I am sure.

[comment]

13 minutes ago, rob said:

The paragraph just was not very clear but that is just me I am sure.

No, it's rather opaque to me as well. As are many other instances in Filemaker Help. I think it means that the current record (and its related records, if any of these are open) will remain uncommitted until you commit them using some other method.

Note that "multiple uncommitted records" (in a single window) can only be related records.

[rob]

Hello Comment,

It would have been nice if they would have said it as clearly as you just said it.  So 'multiple uncommitted records' is like if I modify the parent on the present layout and also modify a child record in a portal or even out of a portal just placed on the layout or even use script and Set Field over to a child table, e.g. 'multiple records' = parent plus child or children and not multiple parents like in a found set.  It is coming clearer, thank you.

And window transaction just means the current window aka layout window and the actions taking place in 'that window' from moment of opening a parent or child up by making a modification until moment of commit.  They call that a 'transaction' which kinda fits what Todd Geist talks about in 'transactions.'

Another thing it says there about "what makes a commit" is not quite right according to my testing but I have not tested on server yet and may be wrong.  It says Data is committed when you "click anywhere outside of the current field" but when I tried it, clicking from one field into a different field does not commit at least data viewer still shows I have the record open.  

I realize I am only getting started with my understanding but this has made a huge difference already.

Thank you too Wim.  I had read you saying this before somewhere which is why I started this tread.  I did not want to commit needlessly so that meant I need a better understanding so I did not continue my behavior of just committing when in doubt which was constantly. 

And Kris M, thank you as well.  I have read help but not enough to remember this page.  I appreciate the link.

Edited January 22, 2016 by rob

[comment]

9 minutes ago, rob said:

and not multiple parents like in a found set.

Since going to another record commits the current record, I don't think there is way to have more than one open record in all the found sets of a single window.

 

15 minutes ago, rob said:

clicking from one field into a different field does not commit

Correct: you must click on the background.