Repeating fields, all pro's!

[Anders]

Hi everyone

Can any of you pro's present a situation where repeating fields are a good/the best solution. I have read quite a lot on repeating fields in this forum, and the quintessence of it all is "repeating fields are bad, they are of almost no value at all". But my curious mind can't get pass the almost. It is logic to assume that if something almost lack value, on some rare occations it has it. When do that occur? The question may just sound like a joke, but it is more than that. I am actually curious.

TIA

PS I think I may have found a situation where repeating fields are the best available solution.

[Fitch]

One thing repeating fields can be handy for is using global container fields to store graphics that you use as "flags" in scripts and calculations. E.g., store a yellow square in rep. 1, and a red square in rep. 2. Then use rep. 1 for an invoice that's over 30 days due, and red for over 60.

I always have one or two global text fields to use for variables in scripts, and it occurs to me that it might be a good idea to just make one global with 100 reps so you never run out of variable storage in a script!

[LiveOak]

I'll admit to using repeating global container fields (or repeating container fields in a Preferences file with one record) to store colors for use a calculated backgrounds. (If you ask me any questions about my own OLD office databases, I'll deny everything and change the subject back to client designs.)

The real danger in using repeating fields is that it is hard to extract data from them. Example, using repeating field to build an invoice:

Qty PartNo. Description Price Subtotal

This works fine until you want to know how may of widget 123 you have sold. Or wamt sales quantity summarized by part number. Oops! No easy way to get this information out of a single Invoice file built using repeating fields. On the other hand, if an Invoice file with a related Invoice Items file is used, the summary report can be created in this file.

So many newbie's get started with repeating fields because they are unfamiliar with relational database structure and a familiarity with spreadsheets causes them to latch onto and use repeating fields to emulate that structure. After they have done so, they don't want to go back and rewrite their files and "just this once" want some arcane method of getting out of the corner they have painted themselves into.

-bd

[SteveB]

While verybody will tell you that repeating fields are a pain and should never be used, there are a number of instances where they can be effective besides storing color swatches and graphics.

A good rule of thumb is if the data does not need to be searched or summarized, you might get away with using them. I have a situation where I'm displaying a list of documents with associated status fields and dates. The user never needs to search these fields, only set them with value lists and a pop-up calendar and then display them. I guess I could have made everything relational, but that would have meant more maintenance, not less. Especially when you look at having to print this info...you can't really print a portal which is how I would have displayed the documents if I didn't use repeating fields.

I guess what you really need to do is THINK about how the data will be massaged, view, summarized, etc. Had FM done a better job of implementing repeating fields, everybody wouldn't this negative. They do have their uses, limited as they may be!

[BobWeaver]

I have occasionally used them. The point is, repeating fields should not be your first choice; they should be the last resort. If after careful consideration, they do the job better than anything else in a particular situation, then fine, use them.

I have used them for the following:

1. Generating a relatively static table of data that never needs to be searched, sorted, indexed etc.

2. Creating a simple spreadsheet-like calculation form where the user fills in the items in repeating fields and then repeating calculating fields tote up the results. Eg, an on-screen price calculator that the user can use to generate a sale price which is then entered into a regular non-repeating field.

3. Holding data that will be imported into another file and split into multiple records.

The common thread here is that the repeating fields hold transient or temporary data that never needs to be looked at again in its repeating field form.

[Anders]

Hello everyone

Great to hear from you. I just thought I'd try to see what you have to say about my usage of repeating fields.

I use them for something I call Keywords. There is a swedish word which I will not bother you with that could be translated into something like "subject word", (and there is a wonderful german word "schlagwort").

The best example I can think of is a library catalogue with lots of books, that sometimes share none or one, ore more keywords.

What I want to achieve is to be able to search a certain (for instance repeating) field (why not call it Schlagwort) for books/records that match some criteria. But furthermore I want to be able to publish a search form on the Internet using Web companion, where all search results includes an URL generated from the Schlagwort-field pointing back at the same field.

I may make a search for say Dogs in Schlagwort and find 4 records, where one of the records also have a Cats-keyword from one of the repetitions that don't contain Dogs. As a next step I may decide to go for the Cats-search instead, and since the Cats-keyword is an URL (as the Dogs one) I just click the link and hey presto!

There is a long story published in the portals forum (Portal, complete and utter newbie), where I discuss why Keywords at all, and how. The situation I have described is not the same as the Invoice one, since I probably never will be interrested in calculating anything from my repeating fields. Search them, yes. But I am only interested in knowing how many books have the Dogs (or Cats) keyword in any repetition. The ones that don't match are of no interrest, and even if I put Dogs in all repetitions of a record I will still only find that book/record once in my search - and in this case that is correct.

Maybe I could have done all of this with portals and related fields. But I just don't understand how to

A. Search a named field (Schlagwort) for several different words

and

B. In the hit list make URL:s out of that field and that links back to the same field (Schlagwort)

and actually

C. Being able to have similar keywords in the "same" field, eg. Cat fur, Cat teeth, Cat tails you name it

I can do the URL in the hit list with a CDML-tag that looks something similar to:

[FMP-Repeating: Schlagwort]<a href="http://...FMPro?-db=...&Sclagwort==[FMP-RepeatingItem, URL]&...>[FMP-RepeatingItem]</a>&nbsp;[/FMP-Repeating]

(In the book example, a book on cats, dogs, pet-spiders, pet-worms, pet-birds, aquarium fishes and lots of other pet animals simply would have the keyword Pets; as would the book on only cats, but with Cats in some other repetition. There is an alternate solution to adding an abundance of repetitions, and that is moderation.)

As I stated earlier on, this case is not to be compared to much with the Invoice case. And hey! Repeating fields work fine for me. Gaarghhhhhh!

Cheers

Anders