There are two issues here.
First, if your times are more precise than to the second, datediff will
be inaccurate, since it returns the number of "seconds boundaries"
between values. So two values just 3 milliseconds apart but right at
the "turn of a second" could have datediff(s,...) of 1, while a
different two values 997 milliseconds apart, but not straddling an exact
second moment could have datediff(s,...) of zero. You can be somewhat
more precise with cast(datediff(ms,...) as float)/3600000, though SQL
Server datetime values have a milliseconds value ending in 0, 3, or 7 -
being accurate only to about 1/300 of a second.
Also (a less likely cause, I think), you may be thinking that FLOAT(8)
means 8-byte floating point, but in fact, FLOAT(8) is the same as REAL,
good-old single precision floating point. The SQL standard supports a
parameter to FLOAT that indicates a minimum number of binary digits for
the mantissa. SQL Server translates FLOAT(n) for n up to and including
24 to REAL, and FLOAT(n) for n between 25 and 53 to FLOAT.
See the Books Online article "float and real" for details, or just see
if using float, not float(8) helps any.
-- Steve Kass
-- Drew University
-- Ref: 747EBB5C-6AB5-4F9C-865D-667487C1B330