Can't seem to find an answer to this possible solution. I have a FM10 app
that is a collection of song lyrics. These lyrics are pre-arranged into
groups (sets) so that they can be displayed to the user as the songs are
being performed. There are two fields for this purpose, set and set
sequence. Let's assume there are 100 songs and the singer arranges 30 of
them into 3 sets (10 in each set). So the set/setseq fields would be set to
1/1, 1/2, 1/3... 2/1, 2/2, 2/3 etc...

This worked very well until the user decided he wanted to play in different
bands. A "band" table was added so songs could be filtered based on which
band he was playing with at the time. This is a simple 2 field table, band
number and name. However this complicates the displaying of sets. If user
wants to play (or more specifically rehearse) Song1 in set/seq 1/1 with
Band1 but wants to rehearse it in set/seq 3/5 with Band3 he has to redo the
set lists every time he changes bands.

I know I can add a "set" table between "bands" and "songs" to accomplish
this but was wondering if it could be done with repeating values. For
instance in our scenario above the set/setseq values would be set to 1/1 in
the 1st repeating values for Song1 with Band1. But they would be set to 3/5
in the 3rd repeating values for Song1 with Band3.

Can this be done? I tried setting up a mod value trigger to call a 'set'
script but I can't seem to get the values to populate as expected. The
values are always changed to the first repeating value. See applicable code
below.

set variable[$$BandChoice; value:songs::_BandChoice] where
songs::_BandChoice is a global fld chosen by user via drop down at startup
set field[song::set[$$BandChoice]; song::set]

Any feedback will be appreciated.

On Sep 24, 9:04*am, "GSteven" <GSP@DavClaServ> wrote:
Don't use repeating fields. They're terrible for this purpose.

"Grip" <grip (AT) cybermesa (DOT) com> wrote

Yep. Repeating Fields are nothing but a pain in the sui-upon and should be
avoided at all costs ... the only exception can be when simply STORING data
(e.g. I often use them to store phone numbers - home, work, mobile - since
they don't ever need to be manipulated at all). For anything that requires
manipulating the data they are hopeless. Change the database structure to
use a separate table and relationships instead.

Helpfull Harry )

I appreciate the feedback from HH and Grip. I was just wondering if any one
else had found a way to use repeating values yet. My experiments with them
brought me to much the same conclusion but was wondering if I was missing
something.

I'll add the "sets" table.


"GSteven" <GSP@DavClaServ> wrote

On Sep 25, 7:41*am, "GSteven" <GSP@DavClaServ> wrote:
Repeaters are legacy features. They've been around forever and FMI is
loathe to get rid of anything, since that would prevent people from
using the new versions of the software with their old databases.

I do use repeating fields for presenting interface data (like a
navigation bar) and for some types of calculations, but almost never
for holding user-entered data, not even phone numbers.