Hi all,

In contrast to some other people in this discussion (and in many other QotD related discussions), I really don't care about points. Points are just a fun way to attract more audience to what should be a mix of fun and education. And the latter (the educational part) is what worries me when I see incorrect answers being marked as correct - and worries me even more when I see absolute bad practices being advertised as a correct answer, without even a disclaimer that this should never be done in a real system.

If you were a DB developer in the US and you built your query around the letter a being or not being in the name of the month, I'd fire you immediately. Many other countries have better job protection, but in those other countries, this code wouldn't even pass the first tests, since most languages seem to have different letters in some of the month names. (And for the record, the code using LIKE '%a%' would also fail on any English server with a case sensitive collation, as neither April nor August contains a lowercase a character).

The error with dob instead of hire_date is just an unfortunate error. Stuff like that happpens. It's a bit unfortunate in that people start doubting whether it's a deliberate setup to check how careful you read the answers or an oversight - but that's nothing one should worry about. If that were the only problem with today's QotD, I wouldn't even have bothered to post.

But the date selection on a letter in a month name - that's just terrible. The following thiings are wrong with it:

* Code relies on language settings and case sensitivity and is hence very unreliable

* Code is unnecessary hard to understand, making future maintenance a nightmare

* I didn't test to confirm, but I expect this code to be slower than the MONTH(...) IN (...) version.

Once more - for the first reason alone, I'd terminate your contract immediately if I were your boss and we were in a country where there are no laws against such termination; for the latter two reasons, I would not terminate you but have a long and stern talk about coding for future maintenance and coding for performance. (And the jury is still out on whether that might be a harsher punishment that immediiate termination :D).