>>1) I doubt the table is so large that it'd make much difference, and if the table so large it should be in a higher performance database engine for lots of reasons.
>>
>>2) This also seems like it's a once-a-day or once-a-week query to send out a company email wishing people happy birthday
>
>Indeed, the Local Cisco Academy where I work wants to send birthday greetings to 1000 or 2000 students - and do this about once a week.
>
>I am more worried about the ease of programming and the robustness of the program, than about execution speed. And I suspect most similar cases would have similarly small tables.
>
>On the other hand, I can imagine that an index ONLY on the month and day might speed things up - for those unlikely cases where millions of birthdays must be managed...
>
>The search in this case might be something like str(month..., 2) + str(day..., 2). That would take care of Feb. 29, but the end-of-year would still have to be handled separately.
>
>I am having this additional idea...
>
>

>select * from People;
>  where right(dtos(dob), 4) between right(dtos(ldStartDate), 4) and right(dtos(ldEndDate), 4)
>

>
>This would take care of Feb. 29, but not of the end-of-year case. I was also considering the option of just restricting input to a single year, and let the user do two separate searches in exceptional cases. Just to keep the whole system simple.

I didn't see this message, but I think you didn't see my yesterday's message too where I proposed a solution that should work and I think should create optimizable query.