Conditional Check within a loop

[msix]

I have a set of records that are sorted alphabetically from A to Z by the value of the field CLIENT and need to assign a sales rep by CLIENT for each location. For example, I might have 10 records for Company X, but they are 10 separate locations that need to be managed by the same sales REP. I need to assign a sales rep's first, middle & last initials (e.g. FML) per CLIENT group for all locations. After the records are sorted, I want to popup a dialouge to ask me for the sales rep's initials for the first CLIENT. Once I enter the initials, I want it to go to the next record and use the previous value entered if the CLIENT is the same, regardless of the location. WHen the CLIENT value is different, I want the previous popup dialogue box again asking for the initials, and have it continue to use that value as long as the CLIENT value remains the same until all records are done. Here's my script but it's stopping after the first successful acceptance of initials. It's stopping when the CLIENT value changes and I'm stuck.

Go to Layout ["Client" (Client))]

Perform Find [Restore]

Sort Records [Restore; No dialog]

Go to Record/Request/Page [First]

Show Custom Dialog ["Client Input"; "Enter Sales Rep"; Client::ClientName;Client::SalesRep]

Loop

Set Variable [$$temp_rep;Value:Client::ClientName]

If [Client::ClientName ≠ $$temp_rep]

Show Custom Dialog ["Client Input"; "Enter Sales Rep"; Client::ClientName;Client::SalesRep]

Go to Record/Request/Page [Next;Exit after last]

Else

Go to Record/Request/Page [Next;Exit after last]

End If

End Loop

Thanks for any help!

[bruceR]

Maybe like this?

Go to Layout ["Client" (Client))]

Perform Find [Restore]

Sort Records [Restore; No dialog]

Go to Record/Request/Page [First]

Set Variable [$temp_client ; "" ]

Loop

If [Client::ClientName ≠ $temp_client]

Show Custom Dialog ["Client Input"; "Enter Sales Rep"; Client::ClientName;Client::SalesRep]

Set Variable [$temp_client ;Value:Client::SalesRep ]

Set Variable [$temp_rep;Value:Client::SalesRep ]

Else

Set Field [Client::SalesRep ; $temp_rep ]

End If

Go to Record/Request/Page [Next;Exit after last]

End Loop

[Søren Dyhr]

While I wouldn't dissagree with my learned colleague here, is there however a structural dependency "pending" ... tagging records isn't fully embraced, since the rules strictly speaking only can get circumvented with keyfields.

With Bruce's suggstion could a found set of records be retagged if need be, and this makes it a bit harder to give it's relational approach, since we by this virtue turn into a many2many kind of relation, where only the latest tagging has it's bearing.

However with some knowledge to Filemakers behaviours do we get multi line keys as a substitute for a genuine join table ... allowing us to use a custom function to produce all the keying required.

But as such do I here exploit:

http://fmforums.com/forum/showpost.php?post/355447/

...to create records two relational steps away on the other side of the many2many structure.

Now the grouping of data is here simply a calc'field getting the first char of the persons name, the topic raiser should obviously group around company name, via the summary field. Where the technique I use here is Edoshins Smart summaries:

http://www.kevinfrank.com/download/kf-fast-summary.zip

...with the twist, that I changed JMO's CF from here:

http://www.databasepros.com/FMPro?-DB=resources.fp5&-lay=cgi&-format=list.html&-FIND=+&resource_id=DBPros000663

...in order to aggregate in the right direction. The way I use Edoshins technique is to omit records from the top, so the found set needs to get restored after being munged, hence the use of this:

http://www.sumware.net/robfm2/?p=4

One thing which perhaps needs to mentioned is when the record actually is made, it's actually in the dialog, where the global then recieves the value which needs to get deleted when heading on to next sets assignment.

Is this efford worth it? Well as long as we keep in mind or have a parlovian bell chiming inside our heads when we need to tag something actually is violating the normalforms. Might we ignore the weaknesses implied by it. Since what I've done honestly takes considerably time to establish ...

I do however post it here to get some input as where to simplify the scenario, to get some more tricks up the sleeves ... because this approach fair and squarely lands in David Kachels warning against the "cute and clever" ... but I've enjoyed the exercise!

--sd

Pling.zip