• As I understand it, Standard SQL converts identifiers to upper case internally unless they are delimited. IBM, Postgres, Sybase and Oracle follow this rule. What this effectively means that as long as you avoid delimited identifiers then there is no problem.

    The problem comes when you have delimited identifiers and you get the case wrong. The SQL Standards say that "MyTableID" and "MyTableId" are different. This is fine, as the errors will tell you of slip-ups, until some clever person wants to 'increase the expressiveness of the language by making it possible to add semantic content merely by changing letter case' by defining both a "MyTableID" and "MyTableId" somewhere. Then, there is chaos.

    SQL Server can get things wrong if you choose a case sensitive collation, because it doesn't follow the standard SQL convention: suddenly undelimited identifiers are compared in a case-sensitive way. I'd suggest putting a trap in your code to make sure that IDENTIFIER_CASE hasn't been inadvertently set to SENSITIVE. Dead simple, create two identifiers MyTableID and MyTableId If no error then IDENTIFIER_CASE = SENSITIVE!

    I mention javascript because we have getElementById and encodeURIComponent. I can accept that I'm not clever enough to join the ranks of the observationally sensitive who are able to remember that an ID is camelCased to Id whereas a URI is kept in capitals, but then programming languages were originally designed to be easily understood. -oh yes tbut that is probably a shallow and hollow argument today.

    Best wishes,
    Phil Factor