The Membership Year field is just a calculation ? I'm not sure why you would want a script here when filemaker can do it automatically with a calculation.
MembershipYear Calculation would be Year(Dues::Date)+1 then
click storage options and under indexing put a check mark in the box "do not store - recalculate as needed."
The year will automatically update as the date field changes.
Im not sure what your other scripts do but there may be a better / faster method. Loops are slow.
Thanks for the reply.
I don't know why you think MembershipYr is a calculation. It is, in fact just a numeric value that is set by script. The script looks at the range of the membership year (think Jan 1, 2012 to Dec 31, 2012) and calculates the membership year accordingly. Then it sets the MembershipYr field to that value. No calculated fields here.
That was a question mark. My point is that it would be faster to use a calculation field, if possible. There is not enough data provided to tell what you are doing. The screen has 1 date with a year in a seprate field.
I agree that a calculation field is the better option unless there is some reason that the field has to be a stored/indexed field.
Should that be necessary, you can use Replace Field Contents to do a batch update on your found set of imported data to update such a field. You can use the calculation option to compute the correct value to put in the year field.
I have 'progressed' to thinking that the solution is to go through each record in the portal and run the associated script. This works. But, I don't know how to get FM to go to the 'next' portal row and recognize when it gets to the 'last' portal row. The only functions I can find are get(ActivePortalRow).
Is there some kind of 'fantastic' workaround for this situation?
Given your parallel post, I don't recommend looping through your portal. I could be wrong, but won't you need to loop through portal rows on multiple records?
If you go to a layout based on the portal's table, you can loop through the records that correspond to the portal without needing to loop through the portal rows.
It IS possible to loop through portal rows, that's what go to portal row can do--it just doesn't look like the best option for what you want to do here.
Yes. I created a separate layout showing just the 'affected' field and tried doing a replace (the 'easy' way) but that didn't work. So, plan "B" is to loop through each record on that layout and run the associated script. (Fingers crossed)....
I really appreciate your ideas and insights Phil. It is great to have another 'brain' seeing and commenting on what I am trying to do. Thank you.