[SQL server] datediff op ms geeft verschil terug

[Nukar]

Ik probeer middels een datediff de doorlooptijd van een proces te bepalen in milliseconden (ms).
Begintijd en eindtijd staan in andere tabellen, maar dat is met een join simpel op te lossen.
Mijn probleem zit er in dat SQL server 2005 blijkbaar afrondingen kent op ms.

Wanneer ik mijn uitvraag bepaal een probleem met de resultaten. Ik krijg de verwachte resultaten -1 ms terug. Helaas is dit niet bij 100% van de records het geval. Dus +1 toevoegen in de SELECT is geen optie. Per record geen probleem, maar zodra ik een SUM van 16 miljoen records opvraag wordt het verschil te groot.

Op dit moment gebruik ik:

SQL:

select AAA.UITV_ID, datediff(ms, AAA.B_TYD_UITV, BBB.E_TYD_UITV) 
from AAA
left join BBB
on AAA.UITV_ID = BBB.UITV_ID

/*
geeft 
1773    643
1773    46
1773    656
1773    626
*/

-- datetime velden
select AAA.UITV_ID,  AAA.B_TYD_UITV, BBB.E_TYD_UITV
from AAA
left join BBB
on AAA.UITV_ID = BBB.UITV_ID

/* 
geeft 
1773    2010-10-22 13:42:21.627 2010-10-22 13:42:20.983
1773    2010-10-22 13:42:52.547 2010-10-22 13:42:52.500
1773    2010-10-26 09:08:40.100 2010-10-26 09:08:39.443
1773    2010-10-26 11:36:35.627 2010-10-26 11:36:35.000
*/

Dit is voor elke resultaat 1 ms te weinig. Weet iemand een oplossing waarmee ik dit kan omzeilen?

Google gaf me een mooi voorbeeld van het afrondingsprobleem. Ik weet niet of dit ook de oorzaak van mijn probleem is.

SQL:

SELECT CAST ('8/23/2005 13:01:08.510' AS DATETIME),
       CAST ('8/23/2005 13:01:08.791' AS DATETIME)
/*
geeft 
2005-08-23 13:01:08.510 
en 2005-08-23 13:01:08.790
*/

Zoals je ziet geeft de tweede optie een verschil van -1 ms.

[P_de_B]

Het lijkt erop dat je tegen een probleem met de nauwkeurigheid van datetime aanloopt

DateTime Accuracy
3.33 milliseconds

Values with the datetime data type are stored internally by the SQL Server 2005 Database Engine as two 4-byte integers. The first 4 bytes store the number of days before or after the base date: January 1, 1900. The base date is the system reference date. The other 4 bytes store the time of day represented as the number of 1/300-second units after midnight.

datetime values are rounded to increments of .000, .003, or .007 seconds

Heb je de mogelijkheid om SQL2008 te gebruiken? Daar is een nieuw datatype datetime2 beschikbaar met een nauwkeurigheid in nanoseconden.

[Creepy]

MSDN: Have a Nice Date
Datetime values are stored internally by SQL Server as two four-byte integers, where the first four bytes store the number of days before or after the base date, January 1, 1900, and the other four bytes store the time of day represented as the number of milliseconds after midnight. Datetime stores date and time data from January 1, 1753, through December 31, 9999, to an accuracy of 1/300th of a second (equivalent to 3.33 milliseconds, or 0.00333 seconds), and values are rounded to increments of .000, .003, or .007 seconds.

_{Edit: traag.......}

[Nukar]

Ja dergelijke zaken had ik ook gevonden. Ik hoop (hoopte) dat er een manier bestaat dit te omzeilen.

Heb je de mogelijkheid om SQL2008 te gebruiken?

Nee, helaas nog niet. De uitrol naar 2008 staat wel gepland, maar die komt voor dit probleem te laat.

[RobIII]

Nukar schreef op dinsdag 08 maart 2011 @ 13:11:
Ik hoop (hoopte) dat er een manier bestaat dit te omzeilen.

Niet met de standaard DateTime in ieder geval; wat niet opgeslagen is is er niet
Je zou 't kunnen opslaan in een eigen formaat maar dat maakt meteen alle datetime functies compleet nutteloos tenzij je je weer overal gaat zitten scheel casten.

[P_de_B]

Nukar schreef op dinsdag 08 maart 2011 @ 13:11:
Ja dergelijke zaken had ik ook gevonden. Ik hoop (hoopte) dat er een manier bestaat dit te omzeilen.

Het wordt niet nauwkeuriger opgeslagen dan 3.33ms. Nauwkeuriger data is niet beschikbaar en kan dus ook niet gebruikt worden. Helaas pindakaas.

[P_de_B]

RobIII schreef op dinsdag 08 maart 2011 @ 13:21:
[...]
Je zou 't kunnen opslaan in een eigen formaat maar dat maakt meteen alle datetime functies compleet nutteloos tenzij je je weer overal gaat zitten scheel casten.

Ja, maar dan zul je in je clientcode ook de start- en eindtijd moeten bepalen en die in je eigen formaat (bijv. aantal milliseconden sinds een bepaalde vaste tijd) wegschrijven.

[Nukar]

RobIII schreef op dinsdag 08 maart 2011 @ 13:21:
[...]

Niet met de standaard DateTime in ieder geval; wat niet opgeslagen is is er niet
Je zou 't kunnen opslaan in een eigen formaat maar dat maakt meteen alle datetime functies compleet nutteloos tenzij je je weer overal gaat zitten scheel casten.

&

P_de_B schreef op dinsdag 08 maart 2011 @ 13:25:
[...]

Ja, maar dan zul je in je clientcode ook de start- en eindtijd moeten bepalen en die in je eigen formaat (bijv. aantal milliseconden sinds een bepaalde vaste tijd) wegschrijven.

Euhh nee dank je dat wordt teveel van het goede.

Allemaal bedankt voor de input. Ik ga hier een verslagje tikken waarin ik voorstel deze uitvraag op de plank te leggen tot 2008 is uitgerold.