Tally (or numbers) tables are one of my favorite query writing tools. Such a simple premise that can be applied to a wide variety of problems. If you don’t know what they are, I’d recommend this article. Here is one problem I’ve seen a few times now that you can use a Tally table to easily solve. This is by no means the only way to do something like this, nor is it necessarily even the *best* way, but it is *a* way.
You have a char/varchar column that holds dates in YYYYMMDD format. You now need to cast these values to dates. The problem is, with no validation on the column, some of these values aren’t actually valid dates and you get conversion errors. You’d like to go through and identify anything that didn’t follow the pattern of YYYYMMDD or wasn’t a valid date so that it can be either fixed or removed.
The Tally Solution:
The following query uses a Tally table to generate a range of valid dates that you can check your varchar field against. The below version works in 2000+. (You can just as easily use a CTE tally in 2005/2008)
DECLARE @EndDate datetime
SET @StartDate = '19910101 00:00:00'
SET @EndDate = '20250101 00:00:00'
WHERE vcdatecolumn NOT IN (
SELECT CAST(YEAR(dateadd(d,n,@StartDate)) AS CHAR(4)) +
RIGHT('0' + CAST(MONTH(dateadd(d,n,@StartDate)) AS VARCHAR(2)),2) +
RIGHT('0' + CAST(DAY(dateadd(d,n,@StartDate)) AS VARCHAR(2)),2)
WHERE DATEADD(d,n,@StartDate) <= @EndDate
As mentioned, there are a lot of ways to do this. Because ISDATE() jumps out as being such an easy one, I’ll mention a couple of the problems with using that method. The main gap left is that some of the junk values (fairly common with this setup) like ‘9901’ are valid dates according to ISDATE(). However, it is unlikely that this date is really supposed to be 9901/01/01. You can add a length check, but then you run into ‘9901June’ still being valid, etc. etc. Using the Tally method, all of these are simply flagged as invalid and you can make up your mind about what to do with them once they’ve been identified.