2011-03-02 4 views
2

J'ai une colonne datetime dans la db et quand je teste sa mise enGranularité de datetime SQL


DateTime dateTime = DateTime.Now; 
state.LastUpdated = dateTime; 
Assert.AreEqual(dateTime , state.LastUpdated); 

Je reçois l'erreur suivante
Assert.AreEqual failed. Expected:<3/2/2011 9:52:32 AM>. Actual:<3/2/2011 9:52:00 AM>.

Quelle est la granularité de datetime SQL et est-il possible pour l'accorder pour plus de granularité?

+0

ce n'est pas google-able? –

+0

Eh bien, considérons que les deux réponses fournies se sont trompés ... –

+0

Comme cela fait 10 jours et @Remus n'a pas posté de réponse, je vais poster la bonne réponse afin que vous puissiez le sélectionner pour la postérité. –

Répondre

4

SQL Server est précise à des incréments arrondis de 0, 3 et 7 millisecondes http://msdn.microsoft.com/en-us/library/ms187819.aspx. Vous ne pouvez pas l'accorder pour plus de granularité. .Net DateTime est beaucoup plus granulaire - plus petit que quelques millisecondes, il peut également contenir des ticks. Vous devez garder cela en compte lors de l'affirmation de votre test.

Si vous avez besoin de plus de précision, vous pouvez toujours utiliser un bigint dans Sql Server au lieu d'un DateTime, et stocker le nombre de ticks. (DateTime a un constructeur qui accepte un nombre de ticks Int64.)

+2

Cela n'est vrai que pour l'ancien 'datetime'. Depuis des années, 'datetime2' est disponible avec une précision allant jusqu'à 100 nanosecondes. http://msdn.microsoft.com/fr-fr/library/bb677335.aspx –

+1

Je ne sais pas pourquoi vous parlez de millisecondes ou de nanosecondes. La valeur réelle stockée n'avait pas de seconde du tout, encore moins de petites parties de temps. Cela ressemble beaucoup à 'smalldatetime'. –

+0

@Remus - Merci, je n'étais pas au courant de ça. Dans ce cas, b serait la meilleure option, car une coche représente 100 nanosecondes, donc vous pouvez stocker votre instance DateTime et la recharger sans perte de précision. –