Listen to your feelings. This structure can very easily cause problems for you.
Look up "Portals" in FileMaker Help if you are unfamiliar with them.
You can replace these fields with a portal to a related table. With such a setup, you add more people to your portal just by adding records in this portal.
You should have a related table of item_persons records
You can use a portal to add/display them etc.
Well i sorta know what a portal is, and I use them for other things. not sure how it works for this function tho
your statement makes me question what you are using portals for now if you are having trouble seeing the use here.
On the starter solutions "Expense Report" template, it uses a portal to allow you to have multiple expense types for each record (expense report). however,
however, in table view, it only shows the first expense type that was listed, therefore i don't know how it would allow me to sort by the second or third expense type listed on that particular record.
Since your portal has only one field for a person's name in each portal record, but possibly many records to list many people, you only have to sort on one name field.
I mention the example of the expense report above because at first it seemed to approximate what I was trying to accomplish.
I use portals in this chemistry table where I have fields for a bunch of elemental properties, so when I pull down a particular element from the perioridc table, the appropriate values for those various property fields are filled according to that specific element.
Portals allow you to display multiple related values from a related table. You can also add related records if the functions are turned on via the relationship.
In this case your screenplay item needs to have people assigned to it. In the database world if you can have multiple items connected to a single other item then you usually want seperate tables and 1 for the single item and one for the multiple items (in this case people) this second table is often called a child table similarly to how a single parent can have multiple children. Similarly to how children inherit the surname of a parent a child table inherits a key field(or fields) from the parent record. These are typically the ID fields which are autoenter serial number fields in the parent table. To further ensure that other records can be related correctly the child table also has its own auto enter serial number or ID field (should it be needed later)
A portal lets you view (or add) records in this child table while in a layout based on the parent table. (They can also be used in the reverse but are generally only needed when there can be multiple related records)
You might want to describe what you want to do with your list of people names and what each record in your original table is intended to represent. A single scene perhaps? You may have a many to many relationship here between your original table and a table where you have one record for each character in your screen play.
yes, more or less, each record on my original table represents a scene.
Record/Scene #1 = Cafeteria Food Fight
Person #1 = Sherri
Person #2 = Whoopi
Person #3 = Joy
Person #4 = (empty)
Person #5 = (empty)
Record/Scene #2 = School Musical Auditions
Person #1 = Bill
Person #2 = Sherri
Person #3 = (empty)
Person #4 = (empty)
Person #5 = (empty)
It's just a little awkward sorting scenes by people right now, because if I wanted to group all the scenes w/ Sherri, I couldn't simply alphabetize field "Person #1" because she is in the "Person #2" field in the other scene she's affiliated with.
Which is exactly why you need a related table as this will eliminate that issue for you.
What you do is use a portal based on this kind of relationship:
Scenes::SceneID = People::SceneID
You can use a portal on your Scenes layou to assign characters to a scene and if you enter find mode and specify "Sherri" in the name field in the portal, you'll find all Scenes that include this character.
So my table for "People" should just look like this?
People (field name)
If each name in your example is a different record, yes, but the additional scene ID field to link to records in your Scenes table is crucial to getting the portal to work.
You may also want to consider whether you want to record additional data on each character in your people table. If you wanted to add a thumbnail sketch of each character's personality and motivation, for example, you may want to set up a many to many relationship where you have one people record for each character, but use a portal to a join table to link scenes to characters. That way a single people record can be linked to many scene records and a given scene record can be linked to many characters.
Yes, each name represents a record. However, if I were to, say, import a "roster" of characters from excel, and I had established a field for "People" (names) and an auto-serial number field for "Scene ID" within this "People" table, it will turn out as follows:
People Scene ID
Therefore, when I set up the "People" portal on the "Scenes" table, the portal will display "Sherri" automatically for Scene #1, and "Bill" for Scene #2, if I make the relationship between Scene ID in the Scenes Table and the Scene ID in the People Table.