Discussion :

[aharel]

Bonjour,

Je dois récupérer des enregistrements en base de données par rapport à une datetime précis à la milliseconde.
Le soucis est que je travaille avec SQL server et qu'à priori il y a une perte de précision au niveau des millisecondes lors du stockage du datetime en base.
Par exemple 12/10/2017 14:55:26.222 donne 12/10/2017 14:55:26.223 en base.

Quelqu'un a-t-il déjà rencontré cette problématique?
Je voudrais à la rigueur pouvoir récupérer tous mes enregistrements correspondant à la date du 12/10/2017 14:55:26.222 à 10 millisecondes près, mais je ne sais pas comment faire.

[aieeeuuuuu]

Bonjour,

Utilisez le type DATETIME2 (précision jusqu’à 100 nanosecondes) qui remplace DATETIME (dont la précision est en effet de 3 ou 4 millisecondes).

[aharel]

ReBonjour,

J'ai oublié de préciser que je ne peux pas modifier la structure de la base car elle est utilisée par d'autres applications.
Le champ doit nécessairement rester en DATETIME, d'où mon problème.

[SQLpro]

Mais si, vous pouvez parfaitement passer du DATETIME au DATETIME2(3) qui est son strict équivalent, sans imprécision.

Là je suis en train de modifier le type de 2500 colonnes d'une base en production....

Faites des essais et vous verrez !

A +

[aieeeuuuuu]

Il y a quand même quelques variations de comportement entre DATETIME et DATETIME2(3) qui pourraient poser problème.

Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
CREATE TABLE #DT (a DATETIME);
CREATE TABLE #DT2 (a DATETIME2(3));
 
INSERT INTO #DT VALUES(0);
--> 1*ligne(s) affectée(s)
INSERT INTO #DT2 VALUES(0);
--> Msg*206, Niveau*16, État*2, Ligne*6
--  Conflit de types d'opérandes*: int est incompatible avec datetime2

[SQLpro]

Que vient faire un nombre dans une date ?

Je sais que quelques crétins confondent tout. Mais dans ce cas c'est juste au poteau qu'il faut les mettre !

A +

[aieeeuuuuu]

certes, mais :

1/ m'est avis qu'il va te falloir beaucoup de poteaux...
2/ une fois que tout le monde est au poteau, qu'est-ce que tu fais avec ton appli en vrac ?

le cas que j'ai donné en exemple est assez marginal, mais par contre j'ai souvent vu des "additions" directement sur un DATETIME, ce qui ne passe plus avec DATETIME2 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
CREATE TABLE #DT (a DATETIME);
CREATE TABLE #DT2 (a DATETIME2(3));
 
INSERT INTO #DT VALUES('20170101');
INSERT INTO #DT2 VALUES('20170101');
 
SELECT a + 1
FROM #DT
--> ok
SELECT a + 1
FROM #DT2
--> Msg*206, Niveau*16, État*2, Ligne*21
-- Conflit de types d'opérandes*: datetime2 est incompatible avec int

C'est tout aussi affreux, mais beaucoup plus courant malheureusement.

Bref, faut quand même bien tester avant de passer d'un DATETIME à un DATETIME2, ce n'est pas sans risque.

[SQLpro]

certes, mais :

1/ m'est avis qu'il va te falloir beaucoup de poteaux...
2/ une fois que tout le monde est au poteau, qu'est-ce que tu fais avec ton appli en vrac ?

le cas que j'ai donné en exemple est assez marginal, mais par contre j'ai souvent vu des "additions" directement sur un DATETIME, ce qui ne passe plus avec DATETIME2

Une dateheure plus un nombre de quoi ??? C'est déjà d'une absurdité incroyable.....

A +

[aieeeuuuuu]

C'est déjà d'une absurdité incroyable.....

Je ne dis pas le contraire. Mais tu es bien placé pour savoir que des absurdités, on en voit tous les jours.

Je ne connais pas le contexte de aharel, et on peut espérer pour lui que tout le monde dans son projet utilise DATEADD.
Mais dans le cas contraire, un remplacement par du DATETIME2 risque de poser souci.

[iberserk]

Une dateheure plus un nombre de quoi ??? C'est déjà d'une absurdité incroyable.....

A +

Et oui mais tu sais parfaitement que la DATEADD est assez rarement utilisé pour ajout des jours, le+1 est malheureusement très courant.
J'ai même actuellement pas mal de tables dont les dates sont stockés en INT. avec CAST(dateInt as datetime)