A while ago in a different discussion group, I got into a discussion with some folks about use of repeating fields. Someone had set up a simple database that used repeating fields to hold information about daily events. I politely suggested he might want to consider using a separate table to hold this information, but I then went on to explain how he could achieve his goal with the repeating fields. Suddenly, I found myself being chastised for "encouraging" the use of repeating fields. This led to a lively and slightly rancorous discussion of the whole question, so now I'm wondering how folks here feel about this subject. I've created a poll just for fun, but I'm really interested in hearing individual reasons why you use or don't use repeating fields.

Hi Barbecue,

I will be honest in listing exactly *ALL* instances where I'm using them now with 7.

1) interface purpose obviously, to hold graphics, Tabs and Labels (specially now that you can split-format them)

2) interface-driven portals (dynamic headers acting on the content of the portal)

3) passing script parameters

4) shortcutting a *set* of related calculations, only when these calculations actually wouldn't update anymore (closed invoice lines stats), and when I can clearly reference the repetition row.

5) calendaring (daily infinite calendar ToolBox) but not for any job calendars nor task sheduling based on records from the files.

6) Temporary related value list (self) looked up from a global calculation repetition

7) As a temporary index in some other occasions

8) Looping scripts, involving sub-loops (global repeating counters)

9) Store data as arrays with some of my price-update list

10) As an alias of a audit-trail for synchronization purpose (importing its content as separate records in a SynchroToolTable make the job easier to parse and synchronize changes coming from remote computers - but then the parsing work is done on single records, then reassembled into a new multiline audit-trail.

As a rule, I would never use them

1) if I don't know in advance what the max number of rep would ever be, and more reasonably when it is sure this number is fixed (ex: a year is 12 months whatever should happen in the next few years...and a month will never exceed 31 days)

2) to *store* variable data, unless there's a clear fixed update tied to it.

Deduction : I use them mainly as *utilities*, but they are doing the job I want them to do, even when plugged to relational architecture.

I've inherited and designed several databases which use repeating fields very heavily. Ignorance would be so much easier than starting to slowly work through fixing the poor designs ("Why, oh why didn't I take the blue pill?").

I still believe that they are very useful in certain situations.

We all know that repeating fields are a legacy hold over from previous FMP versions. However they do have a benifit in today FM environment. Repeating field can be used very effective to hold array data, and small definitive sets of related data that will normally remain unchanged. You can set up a repeating field(s) to store the data and you will know exactly where it is and how to get to it, without having to set up specific relationship.

Just a thought