If not repeating fields, then what?

[iMarcW]

I can see that repeating fields are out of favor with database purists, and I don't use them much in our db's. But how can I solve this problem:

We have conventions where people sign up as a group, with multiple people in that group, but we want to collect all of their individual names and print a namebadge for each one. In the past, at smaller conventions, we've had about 20 single fields for people to enter names into (we have online registration through FMU as well as entering data by hand), but then namebadges were printed by printing all the delegate #1's, then #2, and so on, and sorting them by hand back into order. It's silly.

Those are conventions with attendance in the 100's, now we're talking about thousands. I want to be able to print those namebadges (which come six to a sheet that goes through the laser printer) by group, using both the names (which are many per group) and other information about their location (which is specific to the group) on each namebadge.

I'm not sure what to do. Having an individual record for each name isn't an option, unless there's a way for online registrants to write to two databases at once or to create 20 new records at once in a separate database that's relatable to the main one. Even with repeating fields, I don't know how to print each repetition, intermingled with other data, into its own layout.

Maybe export the info for each repetition of the field separately, then import all those into a new database and print them out from there? (I don't see a way to export specific repetitions, but I could probably make a calculation field based on getRepetition that I just change the number of for each export, and then script the whole process).

I might have just solved my own problem, but maybe some of you have a better idea or can confirm that this would work.

[kenneth2k1]

Hi:

So, are you saying that you have a file for each group, and the individual records that are in that group are found in that file? I'm not sure why the people would have to put their info into two files.

I can suggest one way to fix this, but it might take some time to restructure. Anyways, you would have a file for members and one for groups and they would be related. Each group would be a record iin the groups file and each member would be a record in the members file. There would be a group field in the members file that is a value list of all the group names from the groups file. Because of the relationship, you can pull any group info from the groups file.

Then when you make the name tags, you could sort by group and print.

Or am I missing some important factors?

Ken

[iMarcW]

Here's what's going on. A group wants to come to our convention. The group wants to bring 20 people, so the person registering submits a registration with the names of those 20 people. Membership in our association is by group, not by individual, so the convention database records are already related to our membership database by the group ID number. But the people associated with that group change every convention--sometimes it's 5, sometimes 20, and always different people. So as long as registration is by group, and that's not going to change, the registration has to have all these names associated with it and go into the convention database as one record. As far as I can tell, a repeating field is the easiest way to do that.

I've been thinking more about how to do this as I described in my first post, and here's how I would do it: For each group, there would be a field "Names" with 20 repetitions, with the names in it. Then a field with a numeric value 1 to 20--call it repNum. Then a text calculation field, repText, equalling getRepetition(Names, repNum). Once registration for the convention is finished, I set repNum to the values 1 to 20 in succession, each time doing an export of repText plus the other info I want on the namebadge. I then import these into a new database where every record is a separate name with all the group info attached. I can sort these and print any way I want.

There are two things that would make it easier to script:

* Can you make a loop set a variable and increase it each time through so you can set the value of a field to 1, 2, 3, 4, etc. until you get to 20, then stop? Otherwise I have to use 20 "set field" commands followed by export commands.

* Can you append exported data to an existing file instead of making a separate file each time?

[danjacoby]

Three related files: Conventions, Groups, Members

In the Conventions file, each record is a separate convention.

In the Groups file, each record is one group attending one convention.

In the Members file, each record is one member of one group attending one convention.

You enter the groups into a portal in the Conventions file, then go to the Groups file to enter the individual members. Badges are printed from the Members file.

You can even create value lists to speed up entry of, say, groups that have already attended one convention, or members who are already a part of a group. You can also create a separate file showing, for instance, the history of a particular group, or even the history of a particular member.

[iMarcW]

That would work if someone was manually entering all the records, but how would it work if people registered online? I suppose you could have them enter all the other info into one db, then direct them to the next one and enter the names there--wouldn't they have to enter each name on a separate screen to generate a new record for each name? It seems like more work to set that up than to do it my way.

The names change completely every convention (membership is by group, not individual), so that data wouldn't be of any use to us after the convention was over, so there's not much point in trying to relate them to anything.

I am excited about using more related fields, though. I'm in the process of streamlining our database so that any kind of data that exists more than once per record (not repeating fields, but one field for each year for some types of information, like awards) is getting shipped out into a related database. So for every group, you'll be able to see the conventions they attended and how many they brought, awards they've won, etc., all through different portals.

It's just this one instance where repeating fields seem to make more sense.

[Ugo DI LUCA]

Hi,

Dan is right about the 3 files, but as your "contacts" for the Group may be different in number and in names according to the Convention, you will need to add a 4th file :

Group

Contacts

Convention

+

THE JOIN FILE.

Don't know much about "online things", but I would do the following on a classic platform.

1. A Register Layout (I would store it in the Convention File) that would hold several global fields :

- g_Convention_ID

- g_Group Name

- g_Group_ID (If already exists)

- g_Contact Name

- g_Contact_ID

- g_Other Contact Details (several fields )

A script would :

- check dupes on Contact Name in the Contact db, create an ID there if it doesn't exists

- check dupes on Group Name in the Group db, and create an ID there if it doesn't already exists

- Populate a Join File (The Line Item) with Group_Id, Contact_Id, Convention_Id.

This Join file will be used to print badges,...

A. You will see any contact linked to the group in a portal in the Group db, and could filter this list by Convention_Id using the Line Items.

B. You will see any groups or Contacts linked to the Convention using a portal in the Convention db, using a relationship to the Line Item.

Go Relational, that's the only way you can really achieve this.

2. If you only need to store the Name, then I'll use a "Add to Shopping Kart" method, in the Group db :

- picking-up the names from a selected g_Group (using a filtered portal on Group from previous conventions)

- scripting creation of new Groups in the Group db.

- scripting creation of new contact names in the Contacts db

All these contacts would be stored in a "temporary portal" in the Group db (using for example a global text field (value = "kart") and a constant relationship Group db:"g_kart"::Group db:"textkart" where the text "kart" is entered either within the "picking up from list script" and the "script creation of new contacts".

Then a single script would go to related records and with a loop will populate the line items as in the first method.

Anyway, go relational !!!

[rivet]

Sorry... I know repeat fields are 'poo pooed' but they have a very excellent ability that may help, if I understand the questions completely.

I recently had a similar thing with travellers and multiple luggage tags.

The remaining useful feature of repeating fields it that when you import them into another file there is an option to 'import repeating fields into separate records' and all the non repeating fields get duplicated into each record.

And as for your loop, it is not needed a single import can burst all your groups.

So if you had 10 groups with 10 names in each group, in a single import you would have 100 records.

[iMarcW]

Wow, I forgot all about that feature! Now it makes even more sense to use them. Thanks!

[Vaughan]

"The remaining useful feature of repeating fields it that when you import them into another file there is an option to 'import repeating fields into separate records' and all the non repeating fields get duplicated into each record."

If the values are already in separate related records there is no need to export/import/separate them.

Repeating fields are good for situations where you don;t need to separate the individual values.