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?