It’s so happy to read this your blog. The issue you found in SQL server new datetime type is related time source function precision. Folks have found the root reason of the problem —–when data time values are converted (implict or explict) between different data type, which would lose some precision, so the result cannot match each other as thought. Here I would like to gave a work around solution to solve the problem which the developers met. I use it in my work.

Hopes it helps to the developers met same problem.

Jing

—————————————————————

DECLARE @Intveral INT, @CurDate DATETIMEOFFSET;
CREATE TABLE #TimeTable (FirstDate DATETIME, LastDate DATETIME2, GlobalDate DATETIMEOFFSET)

SET @Intveral = 10000
WHILE (@Intveral > 0)
BEGIN

–SET @CurDate = SYSDATETIMEOFFSET(); – higher precision for future use only
SET @CurDate = TODATETIMEOFFSET(GETDATE(),DATEDIFF(N,GETUTCDATE(),GETDATE())); – lower precision to match exited date process

INSERT #TimeTable (FirstDate, LastDate, GlobalDate)
VALUES (@CurDate, @CurDate, @CurDate)
SET @Intveral = @Intveral – 1
END
GO

SELECT COUNT(DISTINCT FirstDate) D_DATETIME,
COUNT(DISTINCT LastDate) D_DATETIME2,
COUNT(DISTINCT GlobalDate) D_SYSGETDATE
FROM #TimeTable
GO

SELECT DISTINCT a.FirstDate,b.LastDate, b.GlobalDate,CAST(b.GlobalDate AS DATETIME)
FROM #TimeTable a
INNER JOIN #TimeTable b ON a.FirstDate =CAST (b.GlobalDate AS DATETIME)
GO

SELECT *
FROM #TimeTable
GO

DROP TABLE #TimeTable
GO

I have executed the same on sql server 2008 and found that

1- First query returned same results for both columns. Results is below:-

D_GETDATE D_SYSGETDATE
84 84

2- Joins are also working fine.
FirstDate LastDate
2010-07-07 06:55:32.527 2010-07-07 06:55:32.5270000
2010-07-07 06:55:34.777 2010-07-07 06:55:34.7770000
2010-07-07 06:55:34.027 2010-07-07 06:55:34.0270000

Thanks.
Ashutosh

Funny what comes to mind when watching cartoons at morning :)

Second, how much rows there are between 1-Apr-2009 to 31-Mar-2010 and how much rows are between 1-Mar-2010 and 31-Mar-2010? It could be that there’s a lot of rows in the periods that are causing problems and the DB has busy time reading them from the file(s).

Something you could do is to set statistics for io on and run both queries. See what results they produce. Use MSDN to analyze those results.

http://msdn.microsoft.com/en-us/library/ms184361.aspx

I have question regarding datetime datatype.I have one view.I execute it with filter on date.But when i run it for perticular period it slows down .For ex. If I select period 1-Apr-2009 to 31-Mar-2010 then it runs very fine but if i select period 1-Mar-2010 to 31-Mar-2010 then it becomes too slow, I tried a lot to understand the problem but could not.Can you give me the explanation?

Sorry but I don’t quite follow. I think this is normal behavior since FirstDate isn’t as precise as LastDate and so it needs to be rounded.

Situation is almost the same as converting large number like FLOAT to smaller type like INT. You need to get rid of the “extra” bits in FLOAT in order to make it fit into INT. Plus you need to round up any decimals.

Joining works if you explicitly cast LastDate to DATETIME. I’m not sure why it can’t work like that implicitly, maybe there’s some deeper reason I don’t understand. But anyway I think it’s a common problem when comparing two different data types, which vary in size, together.

Btw. Does anyone know how Sql Server gets SYSDATETIME? Does it use performance counter? I think it has to because otherwise it can’t get so precise timestamps from Windows.