Why ever use repeating fields-Best examples.

[Ugo DI LUCA]

Hi,

Why won't we cease our war against repeating fields for a while and build some constructive discussion about what feature we're loosing in not using them.

I'd think the best way would be to explain with some lines of text, or sampler, how you specifically adressed an issue involving repeating fields.

What do you think ?

[Ugo DI LUCA]

Hi,

When trying to migrate our old custom made business solution to a newly created FileMaker one, I ran into some troubles.

Here

[bruceR]

I would easily agree that repeats can be quite useful. I have done a lot with repeats and understand them pretty well. I think there should maybe even be a principal forum topic here on repeats.

But SOOOOO many people here have not mastered basic relational concepts and it is really quite a substantial disservice to them to act as enabler - to move them down a path that makes their future reporting tasks much more difficult, to actively prevent them from learning parent-child and portal manipulation concepts. More so with Filemaker 7, where you can now view and edit data all along the chain of relationships within a single portal. You just can't do that with repeats.

I think maybe a "sticky" topic with solid technical advice on both sides would be useful. "Here are the things you can't do with repeats. Here is why it is really really important to learn database 101 and Filemaker 101. PLEASE gain some mastery of these techniques first, you will be be well served by this knowledge. OK? Now then, here here are 101 cool things you can do with repeats."

I've even thought about writing a book about how to use repeats in Filemaker. Despite appearances, I think that repeats can be valuable and I agree that their use should be understood deeply and accurately.

For instance, the new get(calculationrepetitonNumber) function is wonderful. You can make a complete month calendar with two fields, a start date and a 31 count repeat! Repeats, arrays, lookups, data archiving, applescript manipulation - there is lots to learn.

Long ago I built in FM5.5 someting functonally similar to the single file/multi-table design of Filemaker 7 by making use of repeats. You could define tables with DATA and add and drop them on the fly. You could create cascading relationships and arbitrarily add a muti-row "worksheet" to any record. You can even write your own database structure using repeats. A repeat would contain a tableID, recordID, fieldID, and value. Optionally, it could contain a record lock cell and somem other features. The functionality of the system, including scripts, was all controlled by data and you could just import a new structure or definiton. You could use a single layout to view data from any table.

[Ugo DI LUCA]

But SOOOOO many people here have not mastered basic relational concepts and it is really quite a substantial disservice to them to act as enabler - to move them down a path that makes their future reporting tasks much more difficult, to actively prevent them from learning parent-child and portal manipulation concepts. More so with Filemaker 7, where you can now view and edit data all along the chain of relationships within a single portal. You just can't do that with repeats.

That's why this thread belong to Define Fields rather than one of the Forums here dedicated to Relational design.

The RelVsReps example I'm often refearing too is rather explicit in how repeats can''t be an option when it comes to relational database, except for rather advanced technique.

Thanks for your ideas on the topic.