Question

I am looking for what I think to be a very useful information regarding SQL Server Management Studio.

I have a table with a column of type varchar that stores dates, numbers, and strings.

Those dates are stored with the following format:

dd/mm/aaaa

I have a query that searchs form matching rows and one requirement is that the user must be able to seacrh between dates (period of time).

There is no mistery if I had just dates, I could use a query:

where convert(datetime,a.valor,103) between '01/01/2013' and '03/01/2013'

The problem is that this query fails when reach a row that the value is not a date.

What would be a efficient way to perform that query since there could be thousand of rows to search?

Answer 1

The typical answer is to add a WHERE clause:

WHERE ISDATE(a.valor) = 1

However this is problematic in your situation for a couple of reasons:

1. ISDATE() won’t necessarily match the way you want depending on regional settings of the server, the user’s language or dateformat options, etc. For example:

   SET DATEFORMAT dmy;
   SELECT ISDATE('13/01/2012'); -- 1
   
   SET DATEFORMAT mdy;
   SELECT ISDATE('13/01/2012'); -- 0
   

2. You can’t really control that SQL Server will try and perform the CONVERT after the filter.

You can’t even use subqueries or CTEs to try and separate the filter from the CONVERT because SQL Server can optimize the operations in the query in whatever order it deems more efficient.

For example, with a limited sample, you will probably find that this works okay:

SET DATEFORMAT dmy;

SELECT valor, valor_date FROM (
  SELECT valor, valor_date = CONVERT(DATE, 
    CASE WHEN ISDATE(valor) = 1 THEN valor ELSE NULL END, 103)
  FROM dbo.mytable
  WHERE ISDATE(valor) = 1
) AS sub WHERE valor_date BETWEEN '01/01/2012' AND '01/03/2012';

But I have seen cases with even this construct where SQL Server has tried to evaluate the filter first, leading to the same error you’re currently getting.

---

A couple of safer workarounds:

---

Add a computed column, e.g.

ALTER TABLE dbo.mytable ADD valor_date
  AS CONVERT(DATE, CASE WHEN ISDATE(valor) = 1 THEN valor 
    ELSE NULL END, 103);

To protect yourself from possible misinterpretations at runtime, you should specify dateformat before issuing a query that references the computed column, e.g.

SET DATEFORMAT dmy;
SELECT valor, valor_date FROM dbo.mytable WHERE ...;

---

Create a view:

CREATE VIEW dbo.myview
AS
  SELECT valor, valor_date = CONVERT(DATE, 
    CASE WHEN ISDATE(valor) = 1 THEN valor ELSE NULL END, 103)
  FROM dbo.mytable
  WHERE ISDATE(valor) = 1;

Again, you’ll want to issue a SET DATEFORMAT when querying the view.

---

Use a temp table:

SELECT <cols>
INTO #foo
FROM dbo.mytable
WHERE ISDATE(valor) = 1;

SELECT <cols>, CONVERT(DATE, valor) FROM #foo WHERE ...;

You may still want to use DATEFORMAT to protect yourself from conflicts between ISDATE and user settings.

---

And no, you should not try to validate your strings as dates using string pattern matching as was suggested in another (now deleted) answer:

like '%__/%' or like '%/%'

You will have to have some pretty complex and heavy-handed validation there to handle all valid dates including leap years.