Don't forget to test the demos

by Michael S. Kaplan, published on 2006/03/09 03:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/03/09/546882.aspx


I embarrassed myself a little bit at one of my presentations, yesterday.

I was doing my Tales of Incorrect String Comparisons talk, and I did the following:

  1. On a machine with Windows Server 2003 and an early 2005 CTP build of SQL Server 2005 that supports Windows authentication, create two user accounts on the local machine, named 'AdminЀ' and 'AdminЀЀЀЀ'.
  2. Open up SQL Server Management Studio, pick any database and run the following two queries:

     create user "MICHKAP3\AdminЀ"
     create user "MICHKAP3\AdminЀЀЀЀ"

As I am sure you can guess, that character at the end is one of those that have no weight....

The result for that second query:

Msg 15023, Level 16, State 1, Line 1
User, group, or role 'MICHKAP3\AdminЀ' already exists in the current database.

Basically, SQL Server is validating the entry using its own collation rules -- whether it is doing some sort of optimization here to avoid the performance hit of a call to do the Windows authentication, or whether it is simply storing the entries in a uniquely indexed column that does not allow its own collation rules to be broken, it is clearly not allowing two different valid Windows accounts to be used here.

(this was a problem I had reported early last year, along with another few bugs that were fixed, and I was told this one had been fixed)

Anyway, I then did the same steps on a different setup with a released version of SQL Server 2005 that I had spent half the night installing onto another VPC machine.

I mentioned as this VPC machine was loading that I had just installed it last night and had not even tested it out....

(note to self -- even if I am tired and even if I am not doing a billg demo, I should still check the demo, especially if I am sure that I know what will happen)

The result?

Msg 15023, Level 16, State 1, Line 1
User, group, or role 'MICHKAP7\AdminЀ' already exists in the current database.

I was shocked.

I thought I covered okay by acting dramatic about the situation as if this was what I expected, but the folks who knew me (and at least one of the ones who didn't) noticed I was not expecting that result.

Damn.

Ah well, at least it was a good example of some type of comparison operation that was not being performed correctly.

(And it was not really as bad as the one with Chris and the USB scanner, or even the other one with Tod and the Access 95 demo, a story for another day!)

I think the other examples, of problems that had been fixed were for the most part technically cooler, though I suspect that the one they will remember was the SQL Server one.... :-)

 

This post brought to you by "Ѐ" (U+0400, a.k.a. CYRILLIC CAPITAL LETTER IE WITH GRAVE)


# Maurits [MSFT] on 10 Mar 2006 11:32 AM:

Sounds like whoever filed that bug report didn't test to see if it was fixed...

# Michael S. Kaplan on 10 Mar 2006 11:42 AM:

Well, hard to say (I am not sure who filed the report). Since the other three issues I brought up were all addressed, any of a number of reasons may exist for this one not being addressed (e.g. no one wanted to take the perf hit, or it may have been deemed to be too destabilizing to change, etc.).

Unless you meant me -- in which case I'd point out that I am not the one who filed the bug report. :-)

referenced by

2007/09/05 Head checks containing either comparison or case validation BITE

go to newer or older post, or back to index or month or day