Anyone - thank you!
It is difficult to tell from your post whether you know how to use a "join" table. There needs to be a table for the "join" between a writer and a song. It is really the only correct way to handle cases where there are multiple writers for a song.
I don't really have a simple template for "songs" vs "writers", but I have one for "books" vs "authors", which is much the same thing.
This example file has a fair amount of explanation about how value lists work, and the necessity to block duplicate names, if you expect "name only" drop-downs/popups to work. But otherwise it's just a simple "join" example.
Wow, that is really close to what I need.
Let me see if I can explain it a bit more. Okay, so one of three artists writes this song, we control all 3 artists, each has 33.33%, so is there anyway to turn that trash barrel into a percent pull down? So I could include them but even have 0 % if need be.
I have a few artists who we control and I need to have the writers on a different tab than the main artist I guess.
How would you do it? The template for the songs collection makes no sense, you can list songs but can place them anywhere.
So, I need to have artist, name, percent and the other artists included.
That file was really helpful, especially if I can turn the trash barrel into a pull down.
OK, here's an enhanced version of much the same file. The names have been changed to "Songs" and "Writers". The Royalty has been added. The base Royalty is entered into the Song record. If you add the same Song to a 2nd (3rd, whatever) Writer (which causes a new record to be created in background SongWriters join table), a script runs (via a Script Trigger attached to the relevant field; requires FileMaker 10+).
If the script sees more than one person for that song (using a self-relationship on the SongID in Songwriters), then it asks if you want to reset the Royalties (in SongWriters). It then goes to all SongWriter entries for that song, and splits up the Royalties (each), using a Loop.* It then returns to the original layout.
The same script works from either the Song or the Writer layouts, because they both see the SongWriters join table much the same (thought they use different IDs to it).
*Going to all the entries for the song uses a 2nd relationship, after setting the SongID into a global and Committing the record. By doing this I become free of the portal, and can reliably go to the song's join records for processing.
Oh, forgot. There is also a whole song and dance (and pony show) about the Trash can. I created a Globals table, and created the icon there, in a Container field, and a calculation, with Global storage.
This is how I do Trash (and other) buttons in portals with [x] Allow creation of related records. So the Trash can does not appear on "blank" rows; as that is a little confusing for users. Eliminates the "I click on it and nothing happens!" question.
It is documented on the Globals layout. Many developers have contributed to this idea (years ago).