Looping through repeating fields?

[PatriciaW]

Is there any way to loop through repeating fields without having to specify each one individually using the [n] suffix?

[-Queue-]

If you have all repetitions on one layout and the Tab order set to to move through them consecutively, you can

Go to Field [repField]

Loop

{do something here}

Exit Loop If [Get(ActiveRepetitionNumber) = FieldRepetitions( Get(FileName); Get(LayoutName); Get(ActiveFieldName) )]

Go to Next Field

End Loop

[Søren Dyhr]

Since repeating fields only ought to be used as relationkeys or storage for containers, is it rather limited what you could optain with the knowledge Queue gladly provides you with.

Where he never hessitates, do I instead recommend a study of the implementation if relational database principles such as 1NF avialible in filemaker. Frankly could a lot of scripting be avoided as well as sync'ing issues could be solved, by a proper table structure which doesn't include repeating fields at all.

--sd

[PatriciaW]

I am thoroughly familiar with relational theory and I am aware of the fact that using repeating fields is not 3NF BUT I have been inflicted with converting a database which used repeating fields frequently and I plan on gradually replacing them with separate tables.

However, in the meantime I would like to use them effectively.

I developed a validation routine for telephone numbers which works well for the instance where the database was properly designed, but I wanted to also be able to use it for another situation where there were 6 repeats of the phone number.

What I want to do is loop through the repeating fields and invoke the validation routines inside the loop. Right now I see no reliable way of doing this other than repeating the code 6 times. I did not like the first suggestion because it was dependent upon the tab order on the form. I would like a solution that is not so tightly dependent on the layout.

I'll stick to my present approach if that is not available.

Thanks

B)

[Søren Dyhr]

But why isn't this validation posible on field level ...what does your validation do, that can't be done otherwise than scripted???

Could it be something like Length(Abs(theNumber.... such matters could use this approach:

http://www.filemakerpros.com/VALIDLAY.sit

....although it allmost turns you reasoning upside down!

--sd

[PatriciaW]

The reason that field validations don't work for this application is that I am looking at combinations of numbers and also, for example, one test on area code checks for certain area codes and has to determine whether they are long-distance from the customer's location. If it is then it sets the country code to 1 .... there are far too many possibilities to easily code into field validations (and have it maintainable.)

Even without that ... I have been advised by a number of members that using scripts for validation is the better way to go. It is easier for combinations and also for customizing the validations based on the layout.

[Søren Dyhr]

I have been advised by a number of members that using scripts for validation is the better way to go.

It could be a quite a challenge to establish the facts in it. But what worries me is that you then becomes dependent on event-triggers.

I would think that a lot of developers arrives to filemaker with mind fixed on the discourse belonging to the SQL-sphere not quite willing to adjust to the artifacts belonging to filemaker.

Because the learning curve is so flat, will a lot of the decisions taken be based on assumptions, making other more filemaker'ish ways ignored without even attempts to try.

I think there is a danger in listen to eagerly to established practices if it happens to be based purely on polls or attempts to sniff the newest trend. You should take all advice even the ones with obvious solutions to your problems, with a pinch of salt. Nothing is accomplished if you just implement a solution, without thinking up other solutions to the problem.

Back to your problem, "virtue" is the word for knowing when to restrain yourself and when to break the rules ...and you must consider the reasoning made behind leaving out event-triggers from the tool as well as the reason for having native field level validations. The problem you might face is that the ideas hardly come in a timely manner but instead arrives in lumps ...which is a problem if employed and are supposed to be worth to pay a regular salary.

There is an old programmers saying, that goes:

"So anyone who writes clever code may not be smart enough to debug it"

--sd

[PatriciaW]

It could be a quite a challenge to establish the facts in it. But what worries me is that you then becomes dependent on event-triggers

I don't follow you here. I see no need for event triggers. I did try using them and gave up. I have adopted the approach of having the user click on a button when they have finished editing. Until they do that the record does not get saved and validation occurs then.

I didn't adopt this approach just because of the advice I got, but because in the long run it was the most flexible way for my application. I had spent a lot of unproductive time trying to figure out the best way of validating phone numbers (in a portal) and I was getting very frustrated.

[Søren Dyhr]

one test on area code checks for certain area codes and has to determine whether they are long-distance from the customer's location. If it is then it sets the country code to 1

This point's actually in another direction, which isn't what I nessersarily makes a validation, but instead a formatting of the entry.

Which falls inbetween:

http://www.filemakerpros.com/DecimalDemo.sit

http://www.filemakerpros.com/NUMFORM.sit

--sd