| Author |
Topic  |
|
Kristen
Test
United Kingdom
22191 Posts |
Posted - 05/04/2007 : 12:47:46
|
Actually I suppose its the same as
WHERE IsDate(StringColumn) = 1 AND CONVERT(datetime, StringColumn) > '20070101'
this is BOUND to fail because it admits [to me anyway!] that the table contains invalid dates
Mind you, I'm pretty sure I've been able to get away with this by doing:
SELECT *
FROM
(
SELECT *
FROM MyTable
WHERE IsDate(StringColumn) = 1
) AS X
WHERE CONVERT(datetime, StringColumn) > '20070101'
but maybe I won't be able to under SQL 2005?
Damn good thing if you ask me, StringColumn should be called DateColumn 
Kristen |
 |
|
|
Lamprey
Flowing Fount of Yak Knowledge
3856 Posts |
Posted - 05/04/2007 : 14:33:53
|
quote: Originally posted by Kristen
Damn good thing if you ask me, StringColumn should be called DateColumn 
Kristen
Touche!  |
 |
|
|
Kristen
Test
United Kingdom
22191 Posts |
Posted - 05/05/2007 : 02:02:32
|
Yeah, I know! Trouble some little blighter is going to create it as
DateColumn VARCHAR(24)
 |
 |
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
USA
7007 Posts |
Posted - 05/05/2007 : 13:47:51
|
quote: Originally posted by Kristen
Actually I suppose its the same as
WHERE IsDate(StringColumn) = 1 AND CONVERT(datetime, StringColumn) > '20070101'
this is BOUND to fail because it admits [to me anyway!] that the table contains invalid dates
Mind you, I'm pretty sure I've been able to get away with this by doing:
SELECT *
FROM
(
SELECT *
FROM MyTable
WHERE IsDate(StringColumn) = 1
) AS X
WHERE CONVERT(datetime, StringColumn) > '20070101'
but maybe I won't be able to under SQL 2005?
Damn good thing if you ask me, StringColumn should be called DateColumn 
Kristen
I would use a case statement for that kind of test.
The conditions are evaluated in order only until it finds a true condition, so you can prevent it from attempting a conversion that would cause an error. In the example below, it does not try to evaluate convert(datetime,'xxxx0101'), because the prior test of IsDate('xxxx0101') <> 1 is true.
select
*
from
(
select Number = 1, StringColumn = 'xxxx0101' union all
select Number = 2, StringColumn = '20070101' union all
select Number = 3, StringColumn = '20070102' union all
select Number = 4, StringColumn = null union all
select Number = 5, StringColumn = '20070131' union all
select Number = 6, StringColumn = '20070132' union all
select Number = 7, StringColumn = '20070228' union all
select Number = 8, StringColumn = '20070229' union all
select Number = 9, StringColumn = '20080229'
) MyTable
where
case
when IsDate(StringColumn) <> 1
then 0
when convert(datetime,StringColumn) > '20070101'
then 1
else 0
end = 1
order by
Number
Results:
Number StringColumn
----------- ------------
3 20070102
5 20070131
7 20070228
9 20080229
(4 row(s) affected)
CODO ERGO SUM |
 |
|
|
Kristen
Test
United Kingdom
22191 Posts |
Posted - 05/07/2007 : 04:16:24
|
Is convert(datetime,StringColumn) guaranteed not to be calculated if IsDate(StringColumn) <> 1?
I did try an example indexing StringColumn (even using a Clustered index), in case that got shortcircuited, but it seemed OK on this small data set.
(Query Plan was a Scan using the Clustered Index)
Kristen |
 |
|
|
spirit1
Cybernetic Yak Master
Slovenia
11741 Posts |
Posted - 05/07/2007 : 05:18:59
|
i haven't seen yet that case when ... end would be evaluated anything different than in the order of whens. if you think about it it can't really be evaluated differently. by default when using case you're going to get a scan. so any kind of statistics or anything else doesn't really matter. you still have to do a whole scan. and because of that there's no need to complicate when evaluation order to anything else than from first to last. that's just my 2 cents...
_______________________________________________ Causing trouble since 1980 blog: http://weblogs.sqlteam.com/mladenp |
 |
|
|
Kristen
Test
United Kingdom
22191 Posts |
Posted - 05/07/2007 : 05:35:42
|
Seeing as the whole of the CASE was based on conditions on StringColumn I thought it might have used the Index, but [in SQL2000] it favoured a scan using the ClusteredIndex (and a Table Scan if there is NO Clustered Index)
Kristen |
 |
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
USA
7007 Posts |
Posted - 05/07/2007 : 08:47:02
|
quote: Originally posted by Kristen
Is convert(datetime,StringColumn) guaranteed not to be calculated if IsDate(StringColumn) <> 1?
I did try an example indexing StringColumn (even using a Clustered index), in case that got shortcircuited, but it seemed OK on this small data set.
(Query Plan was a Scan using the Clustered Index)
Kristen
I have been coding date checks like this for years, and have never had a problem with it.
Doesn't prove anything, but if there is a problem, it doesn't seem to occur very often.
CODO ERGO SUM |
 |
|
|
Kristen
Test
United Kingdom
22191 Posts |
Posted - 05/07/2007 : 12:23:07
|
"but if there is a problem, it doesn't seem to occur very often"
Fantastic! That approach works for me too, thanks! |
 |
|
Topic  |
|