Stocker une date

Version imprimable

23/12/2015, 14h19
nesswaw

Stocker une date

Bonjour,

Nous devons stocker une date sous le format: 20151223141515 => AnneeMoisJourHeureMinuteSeconde

Quel type de champs pour ça? BIGINT? CHAR? ou existe-il un champ date qui supporte ce format?

Merci d'avance
23/12/2015, 14h57
Boubou2020

Code:

select convert(varchar,getdate(),112)+replace(convert(varchar,getdate(),108),':','')

merci de lire l'article proposé par SQLPRO http://sqlpro.developpez.com/cours/sqlaz/erreurs/#L7
23/12/2015, 15h14
berceker united

Citation:

Envoyé par nesswaw

Bonjour,

Nous devons stocker une date sous le format: 20151223141515 => AnneeMoisJourHeureMinuteSeconde

Quel type de champs pour ça? BIGINT? CHAR? ou existe-il un champ date qui supporte ce format?

Merci d'avance

En faite, comme ça j'aurais dit l'un ou au l'autre mais ça dépend vraiment de la raison de ce format. Si vous êtes pas obligé d'utiliser ce format je vous conseil fortement d'utiliser le format datetime comme dans la doc de SQLPro proposé ci-dessus. Dans le cas contraire si c'est imposé pour x raison je serais partisan du bigint car sur 8 octets.
23/12/2015, 16h06
Invité

Votre problème n'est pas le stockage.
Pour vous, le problème, c'est de l'affichage.
Stocker ça en DATETIME et faites votre fonction pour afficher ça comme vous le voulez.

Sinon, si vous stockez ça dans un VARCHAR, vous allez vous amuser à réinventer la roue, genre la différence entre deux dates ou l'ajout d'un jour...
28/12/2015, 08h47
nesswaw

Bonjour,

Merci pour vos réponses.

Je reçois cette valeur comme donnée, donc oui je dois la convertir en DATETIME pour la stocker.

J'essaye de la convertir:

select CONVERT (datetime,'20151228') => Fonctionne

Mais quand je rajoute heure, minutes, secondes => select CONVERT (datetime,'20151228084523') => ça renvoie une erreur => Conversion failed when converting date and/or time from character string.

Une idée pour intégrer l'heure?

Merci
28/12/2015, 08h56
Boubou2020

la première méthode

Code:

select convert(varchar,getdate(),112)+replace(convert(varchar,getdate(),108),':','')

deuxième méthode a partir de sql 2012

Code:

SELECT format(getdate(),'yyyyMMddHHmmss')
28/12/2015, 12h14
SQLpro

Pour transformer une chaine de caractère de requête SQL en type de données DATETIME il faut utiliser l'un des deux format ISO :
1) pour les types DATETIME ou SMALLDATETIME (ces deux types étant déconseillé car obsolète), format ISO court : AAAAMMJJ HH:MM:SS.NNN
2) pour les types DATETIME2 ou DATETIMEOFFSET, format ISO long : AAAA-MM-JJ HH:MM:SS[.n[n[n[n[n[n[n]]]]]]]

A +
28/12/2015, 13h10
nesswaw

Citation:

Envoyé par abdallah_mehdoini

la première méthode

Code:

select convert(varchar,getdate(),112)+replace(convert(varchar,getdate(),108),':','')

deuxième méthode a partir de sql 2012

Code:

SELECT format(getdate(),'yyyyMMddHHmmss')

Je dois faire le contraire, la valeur de départ est (exemple) 20151228130912, je dois la convertir pour la stocker dans un champ DATETIME.

@SQLpro: Datetme2? C'est quoi les différences par rapport à l'ancien? Et quand cela a-il été introduit?

Merci

Code:

1
2
 
select convert(datetime, stuff(stuff(stuff('20151228132506', 9, 0, ' '), 12, 0, ':'), 15, 0, ':'))

28/12/2015, 23h33
SQLpro

Citation:

Envoyé par nesswaw

@SQLpro: Datetme2? C'est quoi les différences par rapport à l'ancien? Et quand cela a-il été introduit?

Merci

DATETIME2, DATE, DATETIMEOFFSET ont été introduits avec la version 2008 de SQL Server. Le type DATETIME est considéré comme obsolète et doit être remplacé par DATETIME2 depuis la version 2008.

Le problème du DATETIME est qu'il est imprécis et peut conduire à des requêtes donnant des résultats faux. En sus il pose des problèmes d'estimation des cardinalités pour l'établissement des plans de requête et donc conduit à des pertes de performances. Pour ce dernier cas il est cependant possible de remédier en partie en activant l'option DATETIME_CORRELLATION_OPTIMIZATION au niveau d'une base pour rajouter des statistiques spécifiques afin de mieux estimer les jointures lorsque des clefs primaires / clefs étrangères utilisent une colonne de type DATETIME.

A +
29/12/2015, 14h29
nesswaw
Citation:
Envoyé par abdallah_mehdoini

Code:

1 2 select convert(datetime, stuff(stuff(stuff('20151228132506', 9, 0, ' '), 12, 0, ':'), 15, 0, ':'))
Nickel ça fonctionne:
Code:

1 2 INSERT INTO TestField (Date001) VALUES (convert(datetime, stuff(stuff(stuff('20151228132506', 9, 0, ' '), 12, 0, ':'), 15, 0, ':')))
Mon champ Date001 est de type DATETIME2

Merci beaucoup.

@SQLpro: Merci pour l'explication, je savais pas, ce "nouveau" type de champ est que sous Sql Server ou aussi sur Mysql, Postgres?

Merci bien
29/12/2015, 23h54
SQLpro

Citation:

Envoyé par nesswaw

@SQLpro: Merci pour l'explication, je savais pas, ce "nouveau" type de champ est que sous Sql Server ou aussi sur Mysql, Postgres?

Merci bien

NON, spécifique à SQL Server. D'ailleurs cela ne porte pas le même noms dans PG ou MySQLmerde....

Et on ne parle pas de champs, mais de colonnes !

A +
30/12/2015, 15h08
nesswaw

Merci pour les infos.

Une toute bonne année 2016
03/01/2016, 16h54
elsuket

Citation:

Envoyé par SQLPro

DATETIME2, DATE, DATETIMEOFFSET ont été introduits avec la version 2008 de SQL Server. Le type DATETIME est considéré comme obsolète et doit être remplacé par DATETIME2 depuis la version 2008.

La phrase de la documentation sur ce sujet n'est pas claire : elle ne dit pas deprecated comme pour les autres fonctionnalités :

Use the time, date, datetime2 and datetimeoffset data types for new work. These types align with the SQL Standard. They are more portable. time, datetime2 and datetimeoffset provide more seconds precision. datetimeoffset provides time zone support for globally deployed applications.
La raison invoquée par Microsoft est l'alignement sur le standard SQL, la portabilité, et une meilleure précision comme tu l'écris.
Cela n'implique pas, je pense, qu'ils ne seront plus supportés dans des prochaines versions de SQL Server; d'ailleurs si c'était le cas, j'entends déjà les hurlements à la mort de nombreux éditeurs ... un peu comme pour les curseurs ;)

@++ ;)
04/01/2016, 09h14
SQLpro

Citation:

Envoyé par elsuket

Cela n'implique pas, je pense, qu'ils ne seront plus supportés dans des prochaines versions de SQL Server; d'ailleurs si c'était le cas, j'entends déjà les hurlements à la mort de nombreux éditeurs ... un peu comme pour les curseurs ;)

@++ ;)

On fait le pari ?

A +
04/01/2016, 19h03
elsuket

Ha je veux bien, mais il faut que tu me dises quoi ! :)

@++ ;)
05/01/2016, 04h02
SQLpro

Citation:

Envoyé par elsuket

Ha je veux bien, mais il faut que tu me dises quoi ! :)

@++ ;)

Cela n'implique pas, je pense, qu'ils ne seront plus supportés dans des prochaines versions de SQL Server;

A +
07/01/2016, 13h24
elsuket

J'avais compris, mais celui qui perd doit quoi à l'autre ? :mrgreen:

@++ ;)
08/01/2016, 09h17
SQLpro

Une caisse de champagne !

A +