[v7 General Discussion] Check Schedule adding duplicate songs from Song Select

I have observed that the "check schedule for changes" option is appearing to add songs that already exist in the database.



For example, if you go to song select and choose to put a new song in your schedule, then do a check for changes, it will say this needs added to the database. If you then repeat the process and add the same song to your schedule and check for changes, it will offer the choice to add this song to the database, which is chosen will create a duplicate entry.



I realise that this may not be normal behaviour on one computer, but it happens when I prepare a schedule at home, then transfer to the church. If it is a song I don't have at home, but is on the church, then we end up with multiple copies.



Can you explain why this behaviour is occurring, and any ways to work round it?



Thanks

Hi Niall, Yes this is because the song is different on the back-end. When you add a new song, either from SongSelect or manually, the song is issued an ID for the songs database that categorizes and sorts the songs. The ID is not generated based on the name or anything about the song but is generated depending on other factors like how many songs are in the database. So when you bring the song to another computer, it will naturally have a different ID and the Check Schedule for Changes tool thinks it is a different song.
Thanks Fred,



I've often wondered how this works.



But does this mean that if I bring in the first song entered into my PCs database (song 1) EW will think it is the first song entered into the church database and not register is as new, or is it cleverer than that?
Fred



Thanks for the response. Given it seems to do this on the same computer then it seems a little odd, and does make the check schedule for changes feature a little unusable.



The main purpose for the check schedule for changes is to allow a schedule to be prepared on one computer and then checked with a different computer, ie to allow a user to prepare a schedule at home and then import any changes onto the church computer for future use there. By it not recognising that the songs exists (and should be updated/replaced) creates a position whereby the church computer will have several copies of the same song and no way of validating which one is the normal one used by the worship team.



Examples of why these may have been amended are to use British spellings of words. Is there no way to allow a matching to enable the compare option to be used when importing?



Thanks



Niall
Compare is already an option. See the linked video for more information on the options available in Check Schedule For Changes. Compare is about 3 minutes in.



Hi rvadon



Thanks, and I know about the compare option, but it only gives you that option if it identifies the song already exists.



The issue I have been trying to explain (probably badly) is that the check schedule function appears to identify a song as not existing in the database, even though it patently does. My initial example tried to show that when you add the same song to a schedule from CCLI it adds it as a new song, even though you have just added it.



How it happens in practice is explained as follows:



On day one there are three computers in use (A, B and C), and all have the same database.

On day two, computer A adds a song (10,000 reasons)

On day three, computer B is used for worship, so the schedule from A is loaded and check schedule run, it see that 10,000 reasons does not exist so it adds to the resource area.

On day four, computer C is used to prepare a new schedule (different operator), and 10,000 reasons is to be used, as this does not exist yet on computer C, it is loaded in from CCLI.

On day five, the schedule from C is loaded onto computer B for worship, and check schedule is run. In this instance, 10,000 reasons is flagged as new, and the option given to add to the resource.

This now means that computer B has two copies of the same song.



How can we prevent this from occurring? Or is it a feature of the way that the check schedule operates that we have to live with?



Thanks



Niall