When to commit record in a complex script

[bluearrow]

Hi,

In the following sample script, when should I commit records? Maybe I should do it every time I use the Set field command, but maybe it is redundant. Are there any clear guidelines about it?

Go to layout 1

New record

Set field

...

Set field

Go to layout 2

Go to record

Set field

Go to related records

Loop

Go to record (first by Variable)

Set field

...

Set field

Go to record (Next by Variable)

Exit loop if

End loop

Go to layout (original layout)

Thank you

[Søren Dyhr]

I would say: after the series of set field, unless you IWP your solution - then would I commit immediately after each Set...

The guideline as such it Ilyse Kazars chapter in the Migration Foundations:

http://www.filemaker.com/downloads/pdf/techbrief_fm8_migration.pdf

--sd

[bluearrow]

Thank you Søren,

What if I change record / TO and source table during the script or subscript? Would I need to commit before each of these changes?

[Fenton]

It all depends. This is too vague, too many possibilities, "What if I change record / TO and source table...?" I would say, usually not necessary if you change record, unless you're using one of its fields (including globals) immediately in a relationship; but you do commit after processing the records.

I almost always commit after setting fields (in multiple records) when changing TO or table. There is some question about setting related fields. If you're setting them FROM the parent record, in or out of a portal, then a commit of the parent record commits them. If however you go to a TO and layout of the child table to set them, I commit them there, before returning; even if I'm returning to a field within their portal.

One caveat. Don't commit when clicking within a portal row, until you've either navigated to or captured the ID of the row, as you'll lose focus and be unable to identify which row.

[Søren Dyhr]

This is too vague, too many possibilities

Indeed, your scripting might not be needed at all, because it seems to denormalize data with a set of variables sanwiched in as carriers.

How are these variables loaded in the first place?? Why do you wish to spread apparenet identical data??

--sd

[bluearrow]

How are these variables loaded in the first place??

If I start the script in the parent TO and need to go to related records (a one to many relationship) I use the Go to related record, count them, load 2 variables (Set variable...$start = 1 and Set variable $end = this value). Then start a loop from the first record until $start = $end. This seems to work better than Go to first record, loop until last, in my opinion.

Why do you wish to spread apparenet identical data??

--sd

Some data must be taken from a related TO but could change in the target TO. However, I do not want it to change if the source data changes. If I just copy the parent key and tunnel the rest of the data I would not be able to achieve what the user wants: be able to modify the copied data. The reason to copy it and not just show blank fields is because most cases does not change. But in some instances, it does. It is easier to copy data and let the target field editable. Maybe there is an alternative to this procedure, but I am not aware of it

[Søren Dyhr]

be able to modify the copied data

You have then not considered this:

http://www.filemaker.com/help/FunctionsRef-315.html

It would save a few scriptsteps, wouldn't it??

This seems to work better than Go to first record, loop until last, in my opinion

Only thing is, the other approach have been with us much much longer, ever since fm3 - no one have ever questioned it's reliabality before ...as far as I can recall? Why do you think it works better? Your method is vulnerable to "Omit Record" script steps, while the native handles it!

--sd