Agreed, you don't want to do something that will introduce runtime errors for users. But that's why you can put basic TRY/CATCH statements around the query.

Maybe this is like fingernails on a chalkboard for me, but I don't like users getting the wrong row/incorrect data (nor do I like runtime errors either). Of the two, I'd actually consider bad data the worse of the two.

Like I said, if you've been doing it that way, I don't want to recommend a blind change - though at the very least, I'd suggest a check in your query if you get no results or more than 1 result - because the SELECT @Var = soemthing (by itelf) won't catch it.

Sorry, don't mean to sound dogmatic, but at the very least, I don't agree with SELECT @var = something, unless there are also safeguards in case multiple rows are detected.