A voir également:
- Pb syntaxe SQL
- Logiciel sql - Télécharger - Bases de données
- Jointure sql ✓ - Forum MySQL
- La syntaxe du nom de fichier de répertoire ou de volume est incorrecte ✓ - Forum Windows 10
- Trouver erreur de syntaxe fichier txt pix ✓ - Forum Windows
- Sql (+) - Forum Programmation
5 réponses
il existe la fonction getDate()
mais c pas exactement ca que je veux
je m'explique :
je recupere une date au format JJ/MM/AAAA
que j'utilise dans une requete de type
select * from matable
where madate >= '26/06/2002'
par exemple.
ca parait simple
mais le pb c que le format de ma date dans la base
est MM/JJ/AAAA
ce qui me pose quelque soucis.
précision je peux pas modifier le format de ma date
dans mon code
elle doit etre converti au niveau de la requete.
je sais qu'il faut utiliser la fonction convert
mais je n'arrive pas a la faire fonctionner correctement.
mais c pas exactement ca que je veux
je m'explique :
je recupere une date au format JJ/MM/AAAA
que j'utilise dans une requete de type
select * from matable
where madate >= '26/06/2002'
par exemple.
ca parait simple
mais le pb c que le format de ma date dans la base
est MM/JJ/AAAA
ce qui me pose quelque soucis.
précision je peux pas modifier le format de ma date
dans mon code
elle doit etre converti au niveau de la requete.
je sais qu'il faut utiliser la fonction convert
mais je n'arrive pas a la faire fonctionner correctement.
Recommandation:
N'utiliser que des dates au format ISO !!! (Format : YYYY-MM-DD)
Parole de dba sql server 7.
Raison: les DLL sqlserver font des conversions implicite de format de date, ça peut mener à de terribles erreurs.
Sans parler des couches supplémentaires (ADO, VB, ODBC...) qui font également des conversions selon leur bon vouloir en fonction de la configuration de Windows.
Le format de date ISO est le seul à ne pas être ambigu.
N'utiliser que des dates au format ISO !!! (Format : YYYY-MM-DD)
Parole de dba sql server 7.
Raison: les DLL sqlserver font des conversions implicite de format de date, ça peut mener à de terribles erreurs.
Sans parler des couches supplémentaires (ADO, VB, ODBC...) qui font également des conversions selon leur bon vouloir en fonction de la configuration de Windows.
Le format de date ISO est le seul à ne pas être ambigu.
A mon avis, le format interne à la base des données de type "date"
(à la discrétion du constructeur) est unique, sans doute un format numérique du genre "yyyymmdd" + "hhmmss"+ microsecondes.
Toutes les requêtes (SELECT, INSERT) utilisent un format externe, et un format par défaut (paramètre d'installation ?), par exemple en français : "DD-MON-YYYY", ce qui permet de rentrer une date directement dans ce format (ex : '26-JUN-2002').
Dans les autres cas, on peut utiliser la fonction "to_date({date},'format})" avec un format adapté à l'utilisateur. Autrement, depuis la France, on doit pouvoir attaquer la base, comme si elle se trouvait en France.
... sauf erreur ou omission de ma part !!!
(à la discrétion du constructeur) est unique, sans doute un format numérique du genre "yyyymmdd" + "hhmmss"+ microsecondes.
Toutes les requêtes (SELECT, INSERT) utilisent un format externe, et un format par défaut (paramètre d'installation ?), par exemple en français : "DD-MON-YYYY", ce qui permet de rentrer une date directement dans ce format (ex : '26-JUN-2002').
Dans les autres cas, on peut utiliser la fonction "to_date({date},'format})" avec un format adapté à l'utilisateur. Autrement, depuis la France, on doit pouvoir attaquer la base, comme si elle se trouvait en France.
... sauf erreur ou omission de ma part !!!
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Marden, c'est vrai, mais le soucis c'est que chaque couche que va traverser la requête risque de faire des conversions que tu ne contrôlera pas.
J'ai même eu le cas de DLL Microsoft client SQL Server avec le même nom, même version, même langue qui ont une taille différente et se comportaient différemment avec les dates !
Trop risqué.
Peut importe le format de date interne qu'utilise SQL Serveur pour le stockage des dates: le format ISO (YYYY-MM-DD) est parfaitement compris par le serveur SQL, il ne nécessite pas de conversion d'une machine à l'autre et on est *assuré* qu'il ne sera pas mal intepreté.
Pour moi, plus rien ne justifie l'utilisation d'un autre format de date. Trop dangereux.
J'ai même eu le cas de DLL Microsoft client SQL Server avec le même nom, même version, même langue qui ont une taille différente et se comportaient différemment avec les dates !
Trop risqué.
Peut importe le format de date interne qu'utilise SQL Serveur pour le stockage des dates: le format ISO (YYYY-MM-DD) est parfaitement compris par le serveur SQL, il ne nécessite pas de conversion d'une machine à l'autre et on est *assuré* qu'il ne sera pas mal intepreté.
Pour moi, plus rien ne justifie l'utilisation d'un autre format de date. Trop dangereux.
