Bug in GetRepetition?

[wookie]

I need to copy the values from one repeating field to another. The script I wrote looks like this:

[color:"#666666"]

Set Field ["Field_A","GetRepetition(Field_B; 1)"]

Set Field ["Field_A"-2,"GetRepetition(Field_B; 2)"]

Set Field ["Field_A"-3,"GetRepetition(Field_B; 3)"]

Set Field ["Field_A"-4,"GetRepetition(Field_B; 4)"]

Pretty obvious, however in Field_A only the first value appears, repetitions 2-4 don't show up.

I'm using FM Dev 6.0v3. Is this misbehaviour known as bug?

To solve this issue I'm currently copying the value into a global text field first:

[color:"#666666"]

Set Field ["gBuffer","GetRepetition(Field_B; 1)"]

Set Field ["Field_A","gBuffer"]

Set Field ["gBuffer","GetRepetition(Field_B; 2)"]

Set Field ["Field_A"-2,"gBuffer"]

...

Doing it this way works, although it's quite annoying. Strange, isn't it?

[Fitch]

I've encountered that one myself. Annoying and strange, you described it perfectly.

[CobaltSky]

You'll find that there's an article on the FMI Kbase which acjnowledges this 'limitation', though it stops short of calling it a 'bug'. For interest's sake, the article in question is no 104269 and is accessible online at:

http://www.filemaker.com/ti/104269.html

It suggests the global field work-around that you've already discovered.

However, as was pointed out some time back (on another thread in another place) by the inimitable dj, there is an alternative - and rather more elegant - workaround:

Set Field ["Field_A","GetRepetition(Field_B; 1) & "" "]

Set Field ["Field_A"-2,"GetRepetition(Field_B; 2) & "" "]

Set Field ["Field_A"-3,"GetRepetition(Field_B; 3) & "" "]

Set Field ["Field_A"-4,"GetRepetition(Field_B; 4) & "" "]

For reasons which are somewhat obscure, this will work every time. Inclusion of a null after the referenced value apparently invokes a different part of the application calc code, and gets past the specious prohibition on extending referencing of repetitions on both sides of the script command.

[wookie]

However, as was pointed out some time back (on another thread in another place) by the inimitable dj, there is an alternative - and rather more elegant - workaround:

Kewl! As I heavily use this procedure, getting rid the extra script step saves a huge amount of time. I'll give it try.

Thanks

[danjacoby]

Might I suggest that you move away from repeating fields and into related files & portals as quickly as possible? I think you'll find that, for the most part, your life will be a lot better.

[Ugo DI LUCA]

I was waiting for you on this one Dan

Yep. Escape from Repetitions. They were goods for prior versions of FM !

[wookie]

I use repeating fields in this case to handle localization strings for dialogs, value lists, graphic elements and so on. I seriously doubt that switching to related files & portals make things easier.

[RussBaker]

OK, time for me to buy into this one...

I am a long-time anti-advocate of repeating fields, and normally only use them for storing background colours and graphics. However, I found the following situation interesting:

In one of my mountain bike race timing systems, the Finish Timer display screen shows the name, race category and time for the 15 most recent riders to finish. This is a waterfall type display which is automatically updated evey time another rider crosses the line.

Now, the conventional way of thinking about this is to use a portal which shows the first 15 rows in a "show all completed laps" relationship sorted on finish clock time (descending). However, when you have several thousand people finishing a race, or when the race system is networked, sorting this portal takes a long time, so you can get the situation where the finish timer is not ready to enter the next rider.

I found that by creating a few global repeating fields, each with 15 repetitions, the system was able to produce these results quickly (in under 0.3 seconds) irrespective of the number of riders in the system or the networked status.

[Ugo DI LUCA]

Agreed and apologize, I also use repetition for my containers fields for interface (for example).

Again

[danjacoby]

Actually, I use repeating fields to store dependent value lists. I create a related file in which each record has two fields -- call 'em "Category" and "Subcategory", with the Subcategory being a repeating field.

Now I can create one record for each Category (the main value list), and use the repeating field to create the secondary value list.

But for the most part, repeating fields are garbage.

[Vaughan]

Ok, so apart from being useful for bike race results, dependent value lists, interface images, progress bars and localisation strings, do we agree that repeating fields are garbage?

(Apologies to Monty Python's Life of Brian.)

[Ugo DI LUCA]

repeating fields are garbage....

A poll on this one ?

And for those who wants to laugh on me, here is my first attachment on this forum before I cam up with the horizontal portal trick.

Have fun.

sliding repeating fields

Another proof of some improvements we can make on this forum

[CobaltSky]

Hi Vaughan,

Behind the humour, there is a serious point:

A dictum based approach to development (or anything else for that matter), is not very useful - and with FileMaker can be downright counterproductive.

The fact is that there are *appropriate* times to use just about any FM feature you'd care to cite - *even* including repeating fields, not to mention the list of other popular 'whipping posts' such as printing from portals, record marking, spaces in field names etc etc.

Its fluidity and flexibility is one of FileMaker's chief assets. Folks who want rigidity and rules and fixed parameters would likely be more comfortable using some other product. One gets further with FileMaker in my experience if one puts a pause on the proverbial 'knee jerk' and appraises each case on its merits.

[DykstrL]

I agree with CobaltSky on this one. I have found appropriate uses for virtually every tool and feature in FMPRO - even repeating fields. You just have to be mindful of what you're going to do with the data.

For a set limit of repititions and no intention of (or very limited) data analysis or manipulation of that data, then repeating fields just might fill the bill.

The other issue that needs a little contemplation is if the data is going to be shared or ported to another data set, i.e., SQL or Oracle, or you are drawing data from one of those data sets, then repeating fields are NOT the way to go.

AND, as just about everyone pointed out, they are handy as global containers for all sorts of interface variables.

As much as some people in this forum blast repeating fields and poo-poo them, I wonder how loud those same folks would squeal if FMI removed repeating fields from the FM toolbox?

....just my 2 cents...

[djgogi]

Ray, dykstrl

I'm absolutely agree with you

It is not to use or not ti use some feature but when and where to use them.

Just to add something in favor of repeats, any vectorial and/or iterative calculation would be virtually impossible without them.

dj

[dvalley]

I was looking for just this question when I logged in this morning. I tried the null text method on on set of 40 repeating fields and it worked perfectly. When I tried to do the same for another set of 40 different repeating fields (in the same script), it failed. Any ideas?

[CobaltSky]

One thing to look at was whether the second set of repeating fields were the same data type as the first?

[dvalley]

They were different, number vs text, but when I changed them to be the same, it still did not work.

[CobaltSky]

If the source data is number, then you cannot use a text null to prompt its transfer. Whereas adding a null to text is done with:

TextField & ""

...the way you'd 'add a null' to a numeric value is:

NumberField + 0

If you try to mix data types of the fields, or to mix the data orientation of the formula expressions - ie with constructions such as TextField + 0 or NumberField & "" the technique will fail.

You haven't said exactly what the data types of the source and destination fields were before, or are now, but I'm guessing that if you have matched the data types of the fields and it is still not working, it may be that you are trying to add a text null to a numeric value?