Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2005 Forums
 Transact-SQL (2005)
 DateDiff overflow under the int bound

Author  Topic 

RabidRick
Starting Member

4 Posts

Posted - 2009-01-08 : 02:00:57
Hey there,

I have a strange problem and it's sort of a general question. I can't post the actual source code but...

Using DateDiff caused an overflow when comparing two datetime columns. This would make sense to me if the int value of the DateDiff (respective of the units) was over the max int size but it was in minutes and everything in the table in that column was in the same year (I checked, and I think for mi to overflow would need to be something like 4,080 years difference). Also there were no incorrectly The even stranger part was when I changed "mi" to "dd" it still gave the overflow error.

The REALLY strange thing was the DateDiff statement itself was only throwing the error when compared to a value using the "greater than" operator. For example... DateDiff(mi, start_date, getdate() ) > 0 threw an overflow, but the same DateDiff(mi, start_date, getdate() ) < [whatever arbitrary number] did not error out. It seems this error would have to be caused by the DateDiff function itself overflowing the int buffer size (...I think) and I don't see how the comparison could have any impact at all.

Another thing that might matter is when I got this error I had loaded a pretty large (~1.5 GB) database on an average PC (I think it's a core-2 duo with ~ 2 GB of RAM). I've only seen this happen on this specific box with the DB in question -- when I restored another DB for the app it was fine.

Could this be due to the size of database or something I'm missing in the SQL Server settings? I know it seems like it must be in the data somewhere but I checked... unless it somehow got corrupt

If anyone has seen this error when trying to datediff 2 dates that were absolutely not out of the int size limit for the unit used please let me know.

the actual error: Difference of two datetime columns caused overflow at runtime

RabidRick
Starting Member

4 Posts

Posted - 2009-01-08 : 02:02:53
*there were no incorrectly formatted dates -- only nulls which should be ok

...sorry, couldn't find the edit button >.<
Go to Top of Page

visakh16
Very Important crosS Applying yaK Herder

52326 Posts

Posted - 2009-01-08 : 02:39:40
are you using date values from two fields or two variables?Also are the two fields/variables od datetime datatype?
Go to Top of Page

SwePeso
Patron Saint of Lost Yaks

30421 Posts

Posted - 2009-01-08 : 03:06:43
Something else is wrong. I think you are mislead.
The largest interval possible with INT and DATEDIFF and minutes, are these
SELECT	DATEDIFF(MINUTE, '1753-01-01', '5836-01-25')
SELECT DATEDIFF(MINUTE, '1900-01-01', '5983-01-24')
As you can see, this is roughly a 4,000 year interval.
Have you rebuilt the indexes on these columns?

Please post full query, and we might spot the actual error.


E 12°55'05.63"
N 56°04'39.26"
Go to Top of Page

RabidRick
Starting Member

4 Posts

Posted - 2009-01-08 : 08:05:24
visakh16 - it's comparing getDate() to a varchar column formatted 'mm/dd/yyyy 12:30 PM'

Peso - I think you're right, and no, I didn't rebuild the indexes... This is on a test environment and isn't happening on Production and I think something just went screwy... I just restored to another DB.

I'm just lost as to the reason this could happen.
Go to Top of Page

SwePeso
Patron Saint of Lost Yaks

30421 Posts

Posted - 2009-01-08 : 08:13:47
VARCHAR? You are using VARCHAR to store dates? Why?
Try this
SELECT	DATEDIFF(MINUTE, CAST(start_date AS DATETIME), GETDATE())
FROM Table1



E 12°55'05.63"
N 56°04'39.26"
Go to Top of Page

SwePeso
Patron Saint of Lost Yaks

30421 Posts

Posted - 2009-01-08 : 08:15:15
Or this less forgiving suggestion
SELECT	DATEDIFF(MINUTE, CONVERT(DATETIME, start_date, 101), GETDATE())
FROM Table1



E 12°55'05.63"
N 56°04'39.26"
Go to Top of Page

RabidRick
Starting Member

4 Posts

Posted - 2009-01-09 : 01:09:30
Well, the varchar column is essentially changed to a datetime literal in the query... It should work properly as long as it's in a correct format SQL recognizes as a literal. That's why I checked that all the rows were formatted properly.
Go to Top of Page
   

- Advertisement -