We have several years of customer data that has been collected over time. I'd guess that 95% of the data (Names, Business Names & Addresses) is in all UPPERCASE format.

The data entry tool used within our organization offers an "Export as Proper Case" function. We do not have the ability to modify this data import function. It's an all or nothing switch. We flipped this switch on in January 2013 and since then have discovered numerous data abnormalities:

Original Data          Proper Case Import
-------------          ------------------
McDonald               Mcdonald
MacDonald              Macdonald 
O'Neil                 O'neil
My First LLC           My First Llc
my.email@test.com      My.Email@Test.Com
John Smith III         John Smith Iii

Our data is stored within a closed environment on an iSeries. We have a web interface that allows for single record changes to the data. Unfortunately I do not have the ability to run an update database query to update our data and make mass changes.

What are the Best Practices that you have adopted within your organization with regard to maintaining Proper Case Data vs UPPERCASE Data?

I've got two or three people in the organization that are pushing for Proper Case data on the system. The majority of other people want UPPERCASE data on the system. I'm trying to put together a presentation that states how unrealistic it is to move to a total Proper Case data environment.

What are some good talking points or arguments that support all UPPERCASE data?

  • Are there any Industry Standards or White Papers -- resource requests are not quite welcome at Programmers. As far as I understand, one would rather present an underlying problem instead - a problem that was intended to be solved with particular resource requested
    – gnat
    Apr 11 '13 at 17:25
  • 1
    Thanks @gnat for the recommendation. I have modified the post. Apr 11 '13 at 17:33
  • Sure it's going to be a pain to migrate if you can't run a database query and can't modify your import function. Surely someone has that ability. They should be the ones handling the migration. After migration, proper case is by far easier to maintain in your underlying data, for the reason you've already discovered: it's easy to translate proper case to upper case but not the other way around. Apr 11 '13 at 17:55
  • And now you know why some of those sorts of databases store everything capitalized: BOB MCBLRFL is much less likely to raise Bob McBlrfl's hackles than Bob Mcblrfl.
    – Blrfl
    Apr 11 '13 at 18:23
  • 3
    This is a requirements problem, not a programming problem.
    – Kaz
    Apr 11 '13 at 18:39

I would suggest not coercing user-entered strings into any "correct" format, except for trimming leading and trailing spaces. In the case of data transfer, leave it in the existing format, but store new data as it is entered.

If there is a need for a "correct" case for the purpose of performance, you can coerce both the data and the criteria into an arbitrary case. Better would be to index on an arbitrary case function applied to the data (or create a duplicate arbitrary case column if your database doesn't support that kind of index) and the coerce criteria into that case as well.

For strings, I think the best practice is to trust the user means what they say, because any guessing you perform is going to be wrong frequently. The exception would be when they are given instructions to enter in a particular format, in that case perform the formatting on their behalf wherever possible (i.e.: if they enter in the wrong case, just fix it rather than generating an error).


People's names aren't capitalized using proper case rules. In your example, the correct capitalization of O'neil is O'Neil. Depending on the individual, incorrect capitalization of one's name could be somewhat offensive. There is no sense running the risk of offending a potential customer or (worse!) an existing client by incorrectly capitalizing their name in print and electronic communications with them.

  • 1
    Isn't O'NEIL also incorrect capitalization?
    – Mike
    Apr 11 '13 at 18:30
  • @Mike: In the US (at least) all CAPS is acceptable. It's not as nice as correctly casing each letter, but it's better than incorrectly casing.
    – poke
    Apr 11 '13 at 20:29
  • Can I get an explaination on the down vote? What is wrong with this answer?
    – poke
    Apr 11 '13 at 20:34

This issue is entirely an issue of what the consumers of the data need. It is not a programming issue as either can be accomplished (albeit the propercasing is harder). In the company I work for the users do not ever want to see all uppercase and thus we propercase everything on import. It they wanted all uppercase, we would do that.

You could have a business rule that uppercases the character to the right of the ' or that uppercases the chareter to the right of Mac or Mc (when these appear at the beginning of the name). It would also uppcase II, IV or III when they are at the end of a name. That handles the majority of the people name problems.

If you find exceptions you want handled as you go, you can create an exception table with the propercased version of the name. You can use that fix any names that come to the attention of the company that are not part of the normal rules. This will eventually include almost all of the name problems you have.

Company names and address are more difficult and we just accept whatever our normal propercasing function hands out for imports and whatever is typed in for records added by the GUI. If someone obects to the capitalization we can fix it through the GUI and the import will not update it.


An argument for all uppercase data is that it's the most amenable to internationalization of all the formats. This is why Microsoft recommends uppercasing as opposed to lowercasing in the .NET framework:

Use the String.ToUpperInvariant method instead of the String.ToLowerInvariant method when you normalize strings for comparison.

This may or may not matter for your case.

There are some secondary benefits as well, for example, uppercase letters tend to be easier to read for those with non-ideal vision.

Overall, I can't think of a large number of considerations. Name data is just name data, the casing of it doesn't usually change the context unless you're applying the names into a context rather than just having the name for reporting or statistics-type purposes. So if you were creating welcome messages or something, then the case is probably a lot more important.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.