SQL Server

Data Conversion Woes, pt 2

In Part 1 I discussed why some queries that look like they should work fail with a conversion error. In this part, I’m going to go over some solutions to the problem.

  1. Probably best solution, at least in the long term is, as I mentioned previously, to correct the data type of the column and to remove the data that doesn’t fit. This is probably, however, the hardest of the solutions to implement, due to the potential impact.


Data Conversion Woes

Or “I’m filtering on ISDATE(dt) = 1. Why am I still getting conversion errors?

Well, to put it simply, because SQL’s evaluating the where clause in a different order to what you may have expected.

Let’s try a simple example.

SELECT * FROM tbl_TestingConversion
WHERE ISDate(TheDate)=1
 AND CAST(TheDate AS DATETIME) > '2007/07/01'


An overview of Execution plans

I was asked a question about this recently, so I thought I’d start this blog off with a brief overview of SQL Server’s execution plans.

Simply put, a query’s execution plan is the query translated into a hierarchical set of operators that the query execution engine understands. The query optimiser is responsible for producing this plan.

A query can have a number of different possible execution plans, depending on the resources available on the server, the amount of data in the source tables, the load on the server.