There is no "bug", as this can (and should!) be handled using the "credited as" feature. As of yet, nobody has been able to come up with one single example of two different people who have the exact same name but with a difference in capitalization. As long as that doesn't happen, there's no need to allow both variants to co-exist in the database: you just determine which variant is the most-credited form, use that as the "name", and use "credited as" for any variations.

In this case, you would use NiCole Robinson as the name (you indicate that's what she's mostly credited as), and if you encounter a profile in which she credited as Nicole, you'd enter her as "NiCole Robinson, credited as Nicole Robinson". So there is absolutely no need for Invelos to allow us to have both name variants in the database - the system is "forcing" you to make proper use of the "credited as" feature, though.

I think I know what Ken's on about and I'm sure I've had this too.
It's like the contribution system is able to tell the difference between Nicole and NiCole but the actual cast database doesn't.
So if you have Nicole in your database and you download a profile which is supposed to update it to NiCole the update never happens.
Is that right?

Quoting kdh1949:

Quote:
If it is LOCAL to ONLINE the Value Changes

It has to: we have to be able to correct a faulty entry in an online profile.

Quote:
but if it is ONLINE to LOCAL the Value Does Not Change

I understand how you view this as something negative, but I am actually very happy about this behaviour. All names in my local database are well-researched, and I want to keep them that way. When I buy a new DVD, enter it by UPC and download the profile, I do not want the software to overwrite any existing cast or crew names with different capitalisation, because I simply wouldn't notice anything had changed. This way, your local data is "protected" against such unwanted changes. Once you have a name in your database, it stays that way.

Note that we don't have this "protection" for the studios field: if you have a (correct) entry for "TriStar Pictures", and you download a profile that has "Tristar Pictures" (lowercase "s"), then your old value of "TriStar Pictures" will be overwritten by the incorrect value of "Tristar Pictures". Since there are only three studio fields, you usually notice this immediately, but I certainly don't want DVD Profiler making changes (without asking) to actor names of which I have set the correct capitalization a long time ago if I update or download a new profile.

I do understand that this results in more work if you DO want to have that new data after an update, but surely you do see the merit in protecting your local data from not-necessarily-wanted changes, which would not only happen when you accept an update, but also when you simply add a new profile to your database which contains an incorrectly capitalized actor name of which the correctly capitalized version is already in your database.

So...

Quoting kdh1949:

Quote:
We have to make a manual change to our local actor database to go from Nicole to NiCole or vice versa, but all it seems to take to do this online is have a profile accepted and released.

That's indeed about it.

Quoting northbloke:

Quote:
This may have been deliberate to protect the local database, but now you have the problem that people can now accidentally damage the online database!
For example, you have a profile in which an actor's name is incorrectly capitalised. Someone updates the profile and includes a fix. You download the update but don't notice the name change in the preview so it doesn't get changed. You then change something else on the profile yourself and upload it - with the old capitalisation, and if it's accepted the previous fix is overwritten!

Yes, I can see how that could happen, and it is a bit unfortunate. It all comes down to that you just have to take note of the comparison screen when you're contributing: changes like this will be highlighted, so you're supposed to catch these yourselves. Of course, if something like this slips through, one of the voters could also notice it (for instance: the person who corrected that entry in the first place), and point it out to you. Again: it's not perfect, but I don't really see an "easy fix" for it.