Hi Kevin,

I don't really understand what you mean. Since datetime has a higher precendence than char, the character constants will first be converted to datetime, and then the comparison can be made using the datatype of the column, so an index can be used. How exactly the string is converted to datetime doesn't affect this. Maybe I misunderstand your point?

Anyhow, never indexing a datetime is not a wise decision. Tables that are often queried with a date/time interval in the filter can often profit enormously from a clustered index on that datetime column. The same goes for tables where queries often include an ORDER BY clause for the datetime column. And if a table is often queries with a filter for an exact date/time value, then a nonclustered index can be very beneficial - the large number of possible values in a date/time column (provided it is not constrained to have the time value always equal to midnight, turning the datatype datetime in an effective equivalent of date only) almost guarantees high selectivity, which is an important factor in determining a nonclustered index's effectivity.

Finally, the datetime datatype is not inexact. It is basically a counter of the number of 1/300 second intervals since a fixed starting point (midnight of Jan 1st, 1900), so in many regards it is equivalent to an integer.