Select Case vs If Then Else

[Seth Schrock]

I have recently started using the Select Case function instead of the If Then Else function when there are only two possible values. The reason for this is that I like being able to see what the value is being tested for instead of seeing what it isn't, if that makes sense. What I was wondering is if this is a bad idea. I don't think that it will break anything, but I didn't know if there would be a performance hit.

[Rabbit]

There's no performance hit that I know of. And even if there is one, it would be so slight as to not make a difference.

If I understand correctly, you like to explicitly see the values that match the condition for that branch of code. But there's no reason you can't do that with the if structure. Just change the else to an else if and explicitly define the condition.

But with both the if and select structures, I like to use the else option as a catch all. I will explicitly define all my scenarios, but I always include the else in case I miss something.

[Seth Schrock]

I often provide the Case Else option when using the Select Case option, but not always (though I probably should). Well, that provides the information that I needed. Thanks Rabbit.

[Taaner]

Technically it depends on how the compiler translates the commands but I guess the VBA compiler translates a SELECT CASE the same as IF-THEN-ELSE

Rabbit is correct that you will see no performance difference if the code is executed once, or even ten or hundred times, but if it is a function or in a loop that is executed a million time, it is another question. That is something you learn when programming for high performance environments, or heavy batch jobs, but then you should not use Access VBA

What does make difference on performance (but again not noticable) is how you construct the statement used in the IF-selection. A boolean check will be faster than a string compare.