Currently the programm does some logic, when importing and merging birth years (cast and crew are handled equally, so I omit theese words and call them persons for this post, but every thing said is valid for both of them):

• If there is a person in the local db without a BY and an update (regardless if it is downloaded from the online database or copied in using cut'n'paste) brings a person with the same name and a birth year, then the local person gets the imported BY. The person without the BY is replaced by the person with the BY!
• If there is a person in the local db with a BY and no other person sharing the same name in the local data base and an update (regardless if it is downloaded from the online database or copied in using cut'n'paste) brings a person with the same name and another birth year, then the local person gets the imported BY. The BY is overwritten by the new one!
• If there is a person in the local db with a BY and no other person sharing the same name without a BY is in the local data base and an update (regardless if it is downloaded from the online database or copied in using cut'n'paste) brings a person with the same name without a birth year, then the new imported person gets the locally stored BY. The entry without a birth year does not get created!

- These BY logics alters the birth yeas for all appearances of the person in the local data base (it touches each and every profile, in which the person appears)!
- Please don't beat me, if one of the above rules is not exactly described as it works, but you understand the harm caused...

This behaviour was meant to make the propagation of birth years easier - back then, when they were invented and each and every BY in the local data bases was set to 0000, it might have been a good idea to make the guess that the newly imported BY is valid for most of the local entries...

But today this seems to be a rather awkward breeding ground for invalid and wrong BYs. Each and every time an import to a well maintained data base is done, the user has to check each and every imported BY and check how it was translated to the local data base... rather time consuming.

I'd propose to terminate all theese logics, which are performed when importing birth years. A data set should be imported as it was published in the online data base witout changeing any other data in the local data base!

What does the community think about this issue?

I removed my second statement, because I can't prove it - For the other points the program behaves as described in my initial post.

Checked today with cut'n'paste and found it works the same as the download - which i know for a very long time - and yes, each and every time I get updates from the online db, I check and correct my BYs afterwards.

Please recheck this; if this behaviour is unintended, let's call it a bug (not a feature) and correct it; the correction was my initial intent

Quoting Ken Cole:

Quote:
I'm not closed to the option of changing this behavior, especially as an option.

If, when downloading an updated set of cast and crew, the system could alert us somehow that a birth year is being added to an existing cast/crew entry that didn't have one before, that would be great.

.

Some more oddities around this:

• If you have a profile using the same name twice, one time with a BY and one time without a BY, both entries are matched together and have the same BY!
• If there are two persons in the local db with different BYs and no other person sharing the same name without a BY is in the local data base and an update brings a person with the same name without a birth year, then the new imported person gets one of the locally stored BYs - I assume the smaller/elder one. The entry without a birth year does not get created!