Iterating through records in portal

[Bill Jaynes]

Hello everyone,

I would like to know how a script/calc could look through a group of records

and note which was the first to have a checkbox set; then somehow notify the

following records of this fact so they could set themselves in response.

This is in an estimate where the value of the first item's labor can be taken

at full value, while those that follow lose a portion of their labor value due to

the implied economy of scale.

Thanks

Bill

[Chuck]

Try something like this. This script assumes that your checkbox field is linked to a value list where when the box is checked, the field has a value of 1 and when it's unchecked it has a value of 0.

Try something like this. This script assumes that your checkbox field is linked to a value list where when the box is checked, the field has a value of 1 and when it's unchecked it has a value of 0. If this is not the case, then you'll have to change the If statement at the beginning of the Loop and the Set Field statement within that If statement. gRecord_Found is a global field used to track whether or not you've come across a related record with the check box checked.

Set Field [ gRecord_Found, 0 ]

Go to Layout [ layout with the portal on it ]

Go to Field [ Related_File::Check_Box_Field ]

Go to Portal Row [ First ]

Loop

[Bill Jaynes]

Thanks for your reply, Chuck. It's through people like yourself that folks

like me can learn in a really comfortable way.

I'm studying your suggestion as someone who hasn't done much scripting

yet and who's trying to learn good design sense. My question now is whether

it is better design wise to "get at" different records on a portal in the way

you suggest or by distinguishing different record types through the self join

route (which I have NO experience with!). Reading about self join, it sounds

like a more object oriented approach.

Actually, I could use a recommendation to a text that might help with DB

design issues in FM. I built the one app I use on the strength of one tutoring

lesson and then gutting my way through FM documention. Now I need to make

it civilized enough to market.

Thanks

Bill

[Chuck]

Without knowing more about the technique that you mean when you say "get at records ... by distinguishing different records types through the self join route", I'm not really certain if it would be a better way to go. The method I've outlined is what I normally use for going through related records in a portal.

Regarding a good book about FileMaker and database design, check out Using FileMaker Pro 5 by Rich Coulombre and Jonathan Price.

Chuck

[Bill Jaynes]

I've developed a script that gets my job done so far; after repeated scrutiny of your suggestion.

Now I have a question about sorting. You may remember the need to determine the first occurence of a particular KIND of item; the first gets rated higher in a calc than subsequent occurences of that item type.

When I resort the records, and run my script;

the script ignores the apparent new precedences and acts upon them based on their original order of portal row. The expected change of item data doesn't occur.

Is their something about a sort that needs to be "set" or something?

Oh, now I see this is something connected to the fact that when I sort the records in the

related file, they don't appear to be resorted in the portal in the master file.

"Is this a thicket or what!"

Merry Christmas

Bill