[AndyL]

I was thinking it would be useful to have more than one title for a song. Several songs are known by different names. Black Orpheus, A Day In The Life, Carnival. Lonesome, Si Tu Vois Ma Mere, I Remember When. To name a couple.It would be nice to have all the names in the library, but pointing at the same underlying song.

I know I can copy a song, but that means notes etc wouldn't necessarily stay the same if one was edited.

I suspect this isn't easy with the existing database model. So something to think about for the future.

Andy

[BRX]

I have thought about multiple titles quite a long time. If you're interested in my solution with the available means: I use one of the custom fields for the alternative titles. The main title is in the normal title field, the secondary ones in the custom one (with a delimiter if necessary).

For the secondary title I create a placeholder entry (only a single one even if there are several songs with identical titles)

Finally I use the subtitle to display the other title from the custom field starting with a =>

So it's not an automatic referral but 1 manual step more. But it's the best I could think of and it makes do.

[Harper]

This is an old issue.  I also use a custom field to note the alternative titles but I don't bother with a placeholder ... maybe  cuz I don't really know what the value is of a placeholder.

[Zubersoft]

While I think my code is now set up in a way where I can decouple the lists that are shown from the list of songs in the database (so that the same song can appear multiple times with different titles), I think other issues would be caused by this change. Many of the actions you can take when long pressing and selecting songs are not things that I would want to allow to be done on the same song multiple times, so I would need to add some additional error checking. Also, certain features like the "Automatically Load Next Song" option would result in the same song being loaded multiple times as the songs are paged through (which may or may not be a problem). Some things may get a little weird too when adding songs to a setlist. I would assume I would just use the original title when the song is displayed in the setlist, but if the user had just tapped one of the alternate titles in the list, that might be odd. If I had to track which title was used in the setlist, that would start to get out of hand quickly and add too much complexity.

If I just made the change to the Songs tab, I would be able to isolate the impact of adding alternate titles, making it much easier to implement this change without breaking a lot of stuff. I'm not sure if that's really sufficient for what you want though...

[musichawk]

A thought from other database environments: Allow a song (database record) to have multiple values in the primary Title field, via delimiters, then abstract those at the view level so they appear as different virtual DB records but a click always goes to the one real record. I can imagine this could get complex if the Title field value is the primary key -- how to know which of its multiple values is the real key?

This seems to be how my fave media manager JRiver Media Center works, though not on a Title. In other fields that are specified as multi-value I can, say, enter any number of keywords/tags, then open a view grouped by tags, and each database record appears as many places as it has tag values, but opening/editing is always the same physical record.

But at this point, surgery on the primary Title field might not be feasible. So, another method I've used is to have a second standard field that is an "alias" shadow of the primary field, perhaps called Alternate Titles or Title Aliases, that allows multiple delimited text values. This avoids messing with the primary field. Then have (or perhaps allow) a view/list to show the values from both fields as if they are the same virtual field, the rows of a view/list Title column populated from both fields, creating virtual display-only records that all point to the same real record. The trick is to have any click on any virtual record always view/open the one and only real record.

(I remember Chris Codd always lecturing that primary keys should never be real data, just permanent record numbers that never change. Of course he was focused on multi-table relational database design, but virtual views have some of the same challenges.)