>>The user is the arbiter, not some middle manager. I for one, always look for a single way to do things. If I am custom-hand coding every query and every line of front end code, that is not efficient.
>
>Mike, the point I'm making - and using a bit of the Socratic method - is that people create small "factory" functions in SQL to get this kind of information.
>
>Reading through this entire thread, this has a whiff of a general developer "anti-pattern".
>
>I'm not referring to custom-hand coding every query. That's a straw man argument.
>
>And yes, an I.T. manager WILL sometimes be an arbiter. Especially (to your point) of someone taking an approach that might be the very opposite of a "simple way to do things". I've seen development managers pose the very question.
>
>Really, I'm not trying to be a pain. I'm just curious why there's a compelling reason to go through this trouble when a basic T-SQL approach works perfectly well.

I think in this case you're right - as Rob pointed out, this code can easily create duplicates. You would have to have code on save which verifies that the new ID hasn't been used (and wrap it in some kind of locking mechanism anyway). I generally have a NewID() stored proc. I call through EF. It normally just grabs/stores an incrementing number but it's easy to modify if you run into cases where an operation could be cancelled (and this ID is "lost") but the business doesn't want missing #s in their sequence. It also cleanly handles the multi-update/locking issue.

Definitely an interesting question from a C# perspective - I never would have expected the behavior differences between int/short.