Is there anyway to create users with the correct Windows AD ID cases
so that I'm not having to figure it out then modify the logins for
each AD ID user?
Built in, you already found it -- use the directory searching interface in the GUI. Alternatively, you could use SQL CLR (as mentioned), or write a PowerShell script. You could certainly write a routine to clean up an instance using either method.
Note that the GUI rewrites the domain name, even if it's incorrectly cased when entered, but not the login name itself. (You can see this by manually typing something in, then hitting the Script button.)
But it was returning all lowercase for me, yet all uppercase when I
asked the user to run SELECT SUSER_SNAME() and give me the result. The
correct is all uppercase (...).
Under impersonation, SUSER_SNAME()
returns the principal name as entered. If you try the test again with a different casing, it will return the exact name you typed in. The only reason the impersonation works using an incorrectly-cased name is because the Windows collation says the comparison of the two is a match.
Not under impersonation, there are two cases: (a) group login: the principal name is returned from what Windows supplies, which is always correctly-cased, and (b) individual login: the principal name is returned from what is entered for the name in SQL Server (it doesn't go out to Windows to double-check).
Now, having said all that, try as I might, I cannot replicate this problem using 2008 R2 management tools. If you're still running 2008 (non-R2) management tools, one option would be to try upgrading the tools, because this appears to be a bug in Management Studio itself.
While I would usually leave an answer this short as a comment, this seems to be worthy of breaking with good practice.
No. Nonsense. Absolutely not.
The answer that @gbn gave to the question you reference is valid, regardless of the method of query. Stored procedure or adhoc, the same applies... Query results are not cached.
However, the source table and index data and metadata will be cached
after the 1st use (subject to continued use, load and memory pressure
though)
That is, the results of a query will be evaluated every execution but
the tables(s) (and any indexes etc) used by the query will most likely
be in memory already.
The "some sort of caching for DAO" is client/API behaviour, irrelevant and unbeknownst to SQL Server.
Best Answer
The challenge you'll run into with these approaches is that you've lost information. Explain it to the business users that they've taken a blurry, out of focus picture and despite what they see on t.v. there's no way to make it crisp and in focus. There's always going to be situations where these rules won't work and as long as everyone knows going into this that's the case, then have at it.
This is HR data so I'm going to assume we're talking about getting names in a consistent title case format because the mainframe stores it as AARON BERTRAND and we want the new system to not yell at them. Aaron is easy (but not cheap). You and Max have already identified the problem with the Mc/Mac so it correctly capitalizes Mc/Mac but there are instances where it's too aggressive with Mackey/Maclin/Mackenzie. Mackenzie is an interesting case though - look how the popularity of it has boomed as a baby name
At some point, there will be a poor child named Mackenzie MacKenzie because people are awful beings.
You're also going to run into lovely things like D'Antoni where we should cap both letters around the tick mark. Except for d'Autremont where you only capitalize the letter after the apostrophe. Heaven help you though, if you send mail to d'Illoni as their family name is D'illoni.
For the sake of contributing actual code, the following is a CLR method we used in a 2005 instance for our purposes. It generally used ToTitleCase except for the list of exceptions we built out which is when we basically gave up trying to codify the aforementioned exceptions.
Now that all of that is clear, I'm going to finish this lovely book of poetry by e e cummings