I'm sorry, but I think you are going to extremes here in your argument discussion with GSquared.
Just because you CAN add a persisted computed column and index it force a seek when you have this where clause: "WHERE CONVERT(VARCHAR(25), GETDATE(), 112) = CONVERT(VARCHAR(25), MyDateTimeColumn, 112)", doesn't make it SARGable. Doing that, creating the index, just adds more overhead to system and does nothing to help someone learn better ways of writing code. You could say it treats the symtom, not the problem.
It the case of this WHERE clause, a simple rewrite is much easioer than changing the structure of the database to meet the query.
I think that you misunderstood my message. Below is a quote from my message that says the exact thing that you claim- this is not a SARGable criteria:
Take for example your quote:
"WHERE CONVERT(VARCHAR(25), GETDATE(), 112) = CONVERT(VARCHAR(25), MyDateTimeColumn, 112)" is NOT SARGable, under any circumstances
I completely agree that this type of criteria is not SARGable
Maybe I wasn't clear in my writing, or maybe you took it out of context. It is clear to me and everyone that reads this thread that a query with this type of criteria can be improved by modifying the code and not by jumping hoops and loops as I did. GSquared gave his definition of SARGability and asked me for my definition. I explained that this discussion made me realize that I'm using a wrong definition (my definition was that the query is SARGable if the server can use seek operation without modifying the code) and showed this example as an explanation to show why my definition is wrong (e.g. According to the definition that I've used until this discussion a query like that should have been considered SARGable, but in reality it isn’t).
Adi
--------------------------------------------------------------
To know how to ask questions and increase the chances of getting asnwers:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/