dynamically limiting repeating fields

[fmbot]

i'm new to filemaker, can anyone help me?

i'm trying view a subset of a number of repeating fields. for example, let's say repeating field WEEKS has been defined with every monday of dates 7/26/04 - 7/25/05, making 52 entries, but i only want to show 10 of these dates at a time, starting with a date that is selected in browse mode. i have made a popup list that shows all of these dates to choose from...now how do i make my layout dynamically show only these 10 dates?

i took the specified date DATE1, and made a loop that went through WEEKS, incrementing COUNT by one each time to figure out the corresponding index number of WEEKS. question 1: is there an easier way to find the index number from the value stored in DATE1?

question 2: i then couldn't figure out how to display 10 of the dates in WEEKS, starting with that index number. i tried making another repeating field VIEWWEEKS that had 10 repetitions, then looped through WEEKS starting at COUNT, and have it drop the value from WEEKS into VIEWWEEKS, but that didn't work:

Set Field [iNDEX; 1]

Set Field [VIEWWEEKS[10]]

Loop

Set Field [VIEWWEEKS[10]; VIEWWEEKS[iNDEX] = WEEKS[COUNT]]

Set Field [iNDEX; INDEX + 1]

Set Field [COUNT; COUNT + 1]

Exit Loop If [iNDEX = 10]

End Loop

is there another way to do this?

thanks so much,

fmbot.

[-Queue-]

You can do this with a calculated field. See attached for an example. There is both a single text field and repeating date field result, depending on what you need. Note that the rep field might be better since you can format it in whatever way you like for dates.

LimitedReps.zip

[bruceR]

You are trying to do something that cannot be done with repeating fields. You need to get rid of them. That's why portals and related records were invented. You cannot individually select, sort, delete, import repeats.

[-Queue-]

Obviously it can be done, and fairly simply. No selection, sort, deletion, or import is required. It could be done with a Custom Function if you have Developer; if not, a repeating calculation (with or without a value list function) is the most streamlined way to dynamically calculate these dates on the fly. The one caveat using version 7 for this is that you cannot specifically relate each calculation (for the 'Single' field) to a particular record yet. It has to be a 'global' calculation for all records in a given table.

[bruceR]

It is a waste of the user's time to pursue the manipulation of repeating fields. No selection, sort, deletion, or import is possible with repeating fields and the proposed solution is not multi-user safe.

It is much better to learn real relational concepts.

Yes, you can come up with a convoluted individual script to accomplish this particular task. What happens when another user wants a different subset? A different sort? What happens when two different users want to do something? User A wants one subset, user B wants another? None of those things are possible with repeats, all of those things are common things users do every day with standard Filemaker lists views and portals.

[-Queue-]

Okay, Mr. Broken Record.

Explain how the solution is not multi-user compatibile. It uses a global, so there are no problems if one user selects one day and another user a different day. A different subset would be no problem either. On the single field, you simply change the definition to include another global. On the repeating one, you specify a large number of reps and specify Case( Get( CalculationRepetitionNumber) <= Extend(global), ... ). FM has added this new Get function to make it even easier to accomplish such things. A reverse sort could also be taken into account using the secondary field of a value list.

Perhaps you think these things cannot be accomplished because you haven't seen them done before. But they can and they have and they continue to be, and it's not a waste of user's time, if it solves the problem and doesn't require an extra file, table, or script for every possible change. The related repetitions bug in version 7 makes it more difficult to create dynamic workarounds that worked flawlessly in 6. But once it is fixed, it will be even faster and cleaner to accomplish these tasks.

It isn't always necessary to create a related table, nor is it as efficient, quick to design or modify, and it requires more overhead than may be necessary. And it isn't an issue of learning relational concepts. You can learn them all you want and still be missing out on the incredible power of calculated repeating fields for dynamic (as this situation most certainly is) and/or recursive solutions, either for interfaces or strict calculations.

[bruceR]

I suspect that I can do as much or more with repeats as you. It isn't a question of what CAN be done.

It doesn't really sound like you have read what the user wants. Just a list of dates? Or more likely, a list of dates and associated data from other repeats? The user in fact DID say they want data from "a number of repeating fields." It sounds like the user wants a 10 row set of several associated repeating fields where one column meeting a date criteria. This is trivial to accomplish with a filtered portal and the results are instant and do not require a script.

Now, what happens if they succeed with your method; they get this list of data - and want to EDIT it? Oops. Yet another problem. Can't do that either. It's time to ditch the repeats and go to a portal design.

[-Queue-]

I think we will have to wait for fmbot's response to know for sure, but it doesn't sound to me like he is requesting 'related' subsets of data. And even if he is, it wouldn't be difficult to incorporate them into another calculation, nor would it require a script as far as I can tell. If there is a desire to edit the information, then this could be taken into account as well, although I believe it probably would require a script. In such a case, it may be well-worth be moving to a related table approach. However, from the information provided, I don't think this ascertainment can be made. If the information is merely for dynamic reporting, I see no problem with the approach. If it is to be used for more in-depth processes, then I too would advocate a related table approach. Otherwise, I see it as unnecessarily spent time.

[fmbot]

thanks for your help! sorry, i've been away on vacation, with filemaker far from my mind...

queue's suggestion would suffice to get the dates...that's exactly what i needed to show dates, in a repeating field.

*But*, i'm trying to implement another repeating field, and i think i'm finding the limits of using them. like what BruceR said, in this case i *do* need to individually manipulate specific fields in it. i'll start a new thread regarding this, since it's an entirely separate topic..