TOUT PETIT PB DE SYNTAXE (SQL)
alicia_3107
-
Bobinours Messages postés 2903 Statut Membre -
Bobinours Messages postés 2903 Statut Membre -
Bonjour !
En SQL (Norme ANSI SQL 92) J'aimerai savoir comment écrire une valeur de type date ?
Je m'explique ... Je voudrais par exemple affecter une valeur de type date à un ensemble d'enregistrements filtré
Voici la syntaxe générale
-------------------------------------------------
UPDATE <TABLE>
SET <NOM CHAMPS DE TYPE DATE> = <VALEUR TYPE DATE>
WHERE <CRITERE DE SELECTION>;
-------------------------------------------------
Le PB est au niveau de <VALEUR TYPE DATE>: Supposons que je veuille saisir la date 31/12/2001. Il y a à chaque fois une erreur d'incompatibilité de types (Type mismatch) lorsque je saisie cette date des deux manière suivantes :
1. '31/12/2001' Entre côtes, il la considère comme chaîne de caractères donc incompaible avec le type du champ concerné (type date)
2. 31/12/2001 sans rien, il n'accepte pas cette écriture ...
Existe-il des fonctions de conversions de types par exemple de chaine de caractère à date ? Ou quelle est donc la solution ?
Merci de me répondre,
Alicia.
En SQL (Norme ANSI SQL 92) J'aimerai savoir comment écrire une valeur de type date ?
Je m'explique ... Je voudrais par exemple affecter une valeur de type date à un ensemble d'enregistrements filtré
Voici la syntaxe générale
-------------------------------------------------
UPDATE <TABLE>
SET <NOM CHAMPS DE TYPE DATE> = <VALEUR TYPE DATE>
WHERE <CRITERE DE SELECTION>;
-------------------------------------------------
Le PB est au niveau de <VALEUR TYPE DATE>: Supposons que je veuille saisir la date 31/12/2001. Il y a à chaque fois une erreur d'incompatibilité de types (Type mismatch) lorsque je saisie cette date des deux manière suivantes :
1. '31/12/2001' Entre côtes, il la considère comme chaîne de caractères donc incompaible avec le type du champ concerné (type date)
2. 31/12/2001 sans rien, il n'accepte pas cette écriture ...
Existe-il des fonctions de conversions de types par exemple de chaine de caractère à date ? Ou quelle est donc la solution ?
Merci de me répondre,
Alicia.
A voir également:
- TOUT PETIT PB DE SYNTAXE (SQL)
- Petit point vert snap ✓ - Forum Snapchat
- Petit 2 ✓ - Forum Windows
- Trier du plus petit au plus grand excel - Guide
- Comment imprimer une photo en petit ✓ - Forum Photo numérique
- Point vert sur Snapchat - Forum Snapchat
12 réponses
ANIS a raison Alicia (ou Alice? je sais plus à la fin)
norme SQL2 (SQL 92):
AAAA-MM-JJ
quand tu fais les INSERT de tes valeurs, la syntaxe est
INSERT INTO LATABLE (CHAMP_DATE, CHAMP_2_VARCHAR, CHAMP_3_SMALLINT) VALUES ('2002-01-07', 'broutchmoll', 23)
ce qui signifie en substance que le 7 janvier 2002 correspond au 23 broutchmoll dans le calendrier concombrien (pourquoi se passer d'une occasion de s'instruire?)
voilou.....
norme SQL2 (SQL 92):
AAAA-MM-JJ
quand tu fais les INSERT de tes valeurs, la syntaxe est
INSERT INTO LATABLE (CHAMP_DATE, CHAMP_2_VARCHAR, CHAMP_3_SMALLINT) VALUES ('2002-01-07', 'broutchmoll', 23)
ce qui signifie en substance que le 7 janvier 2002 correspond au 23 broutchmoll dans le calendrier concombrien (pourquoi se passer d'une occasion de s'instruire?)
voilou.....
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
ah, d'accord... alors prends le newsreader de ton coeur et déboules sur fr.comp.applications.sgbd, il y a un mec (auteur du bouquin qui m'a permi de confirmer avec certitude la syntaxe SQL 92) qui s'appelle Frédéric Brouard et qui est une méga tronche sur Paradox, tu peux aussi le joindre directement sur son propre forum en ligne par http://sqlpro.multimania.com
il te sortira de là. Mais attention si tu as fait une connerie c'est le genre à t'envoyer au peloton! il est sympa mais lutôt radical! mais bon t'es une fille et j'ai vu des sacrés durs à cuire devenir des agneaux devant une fille, donc, tu as une chance (-:
il te sortira de là. Mais attention si tu as fait une connerie c'est le genre à t'envoyer au peloton! il est sympa mais lutôt radical! mais bon t'es une fille et j'ai vu des sacrés durs à cuire devenir des agneaux devant une fille, donc, tu as une chance (-:
N'oublies pas les ##qui encadrent la date, je pense que si je ne me trompe, c'est coe ça :
#JJ/MM/AAAA#
tafiscobar
#JJ/MM/AAAA#
tafiscobar
Voici pour l'instant la seule solution proposée
http://forums.multimania.lycos.fr/lire/sqlpro/451516/452053/read.phtml
Mais en inversant JJ/MM/AAAA >> MM/JJ/AAAA
Salut et Merci à tous ceux qui ont répondu !
Alicia
http://forums.multimania.lycos.fr/lire/sqlpro/451516/452053/read.phtml
Mais en inversant JJ/MM/AAAA >> MM/JJ/AAAA
Salut et Merci à tous ceux qui ont répondu !
Alicia
tiens c'est rigolo ça parce que chez moi j'ai essayé (avec Delphi donc) sur table Paradox aussi la solution en quesiton et chez moi ça tourne avec JJ/MM/AAAA
ça doit être une quesiton de paramètres régionaux quand même, mais faudrait quand même que je trouve s'il est possible de faire en sorte que ces derniers soient 'ignorés' parce que ça existe certainement afin que les BDD soient portables sur plusieurs config différentes... c'est bizarre c't'histoire quand même...
ça doit être une quesiton de paramètres régionaux quand même, mais faudrait quand même que je trouve s'il est possible de faire en sorte que ces derniers soient 'ignorés' parce que ça existe certainement afin que les BDD soient portables sur plusieurs config différentes... c'est bizarre c't'histoire quand même...
Bonjour Kinder ! ça va ?
Je crois qu'il s'agit du SE Windows, Ce n'est pas Win 98 Français que j'ai installé mais Win 98 Bilingue Anglais/Arabe.
Et comme en anglais, We say 'July 31st 1978' le mois donc précède le jour (contrairement au fraçais) ...
Je n'ai pas d'autres explications ... Je ne sais même pas si mon explication est bonne, celà dit la fonction CAST n'est pas une manière élégante de saisir une donnée de type DATE ! et la norme SQL92 n'est toujours pas respectée !
Mystèrieusement mistèrieux, Le mystère continue ...
Alicia.
Je crois qu'il s'agit du SE Windows, Ce n'est pas Win 98 Français que j'ai installé mais Win 98 Bilingue Anglais/Arabe.
Et comme en anglais, We say 'July 31st 1978' le mois donc précède le jour (contrairement au fraçais) ...
Je n'ai pas d'autres explications ... Je ne sais même pas si mon explication est bonne, celà dit la fonction CAST n'est pas une manière élégante de saisir une donnée de type DATE ! et la norme SQL92 n'est toujours pas respectée !
Mystèrieusement mistèrieux, Le mystère continue ...
Alicia.
(hop... je parcous rapidement cette discussion).
En SQL, le seul format de date qui ne soit pas ambigu, c'est le format:
YYYY-MM-DD
(format de date japonais).
Tous les serveurs SQL que j'ai cotoyés l'ont correctement interprété.
Les dates DD-MM-YY ou MM-DD-YY ont toujours posé problème, parceque leur interprétation dépend de la configuration du serveur, de la configuration du client (paramètres régionaux) et des bugs de certaines DLL (merci Microsoft).
Je vous conseille donc vivement le format YYYY-MM-DD
En SQL, le seul format de date qui ne soit pas ambigu, c'est le format:
YYYY-MM-DD
(format de date japonais).
Tous les serveurs SQL que j'ai cotoyés l'ont correctement interprété.
Les dates DD-MM-YY ou MM-DD-YY ont toujours posé problème, parceque leur interprétation dépend de la configuration du serveur, de la configuration du client (paramètres régionaux) et des bugs de certaines DLL (merci Microsoft).
Je vous conseille donc vivement le format YYYY-MM-DD
salut seb,
justement c'est ce qu'on soulignait, or il se trouve que l'un et l'autre (Alicia et moi) on se fait envoyer bouler avec cette syntaxe, et j'ai essayé sur Interbase, même prob. Il doit donc y avoir en effet une astuce pour foutre dans le crâne du machin qu'on utilise le format fixe mais là je ne vois pas et n'ai pas pris le temps de creuser plus avant pour le moment pour savoir comment faire comprendre à Paradox, Interbase voire Fox Pro qu'on est en train de lui parler en esperanto et pas dans un dialecte SQL particulier.
justement c'est ce qu'on soulignait, or il se trouve que l'un et l'autre (Alicia et moi) on se fait envoyer bouler avec cette syntaxe, et j'ai essayé sur Interbase, même prob. Il doit donc y avoir en effet une astuce pour foutre dans le crâne du machin qu'on utilise le format fixe mais là je ne vois pas et n'ai pas pris le temps de creuser plus avant pour le moment pour savoir comment faire comprendre à Paradox, Interbase voire Fox Pro qu'on est en train de lui parler en esperanto et pas dans un dialecte SQL particulier.
Les trois possibilités suivantes marchent:
1- select convert(datetime,convert(varchar,'2001/01/14', 112))
2- select convert(datetime,convert(varchar,'2001-01-14', 112))
3- select convert(datetime,convert(varchar,'20010114', 112))
RQ:mais il faut toujours saisir le format : yyyymmdd
1- select convert(datetime,convert(varchar,'2001/01/14', 112))
2- select convert(datetime,convert(varchar,'2001-01-14', 112))
3- select convert(datetime,convert(varchar,'20010114', 112))
RQ:mais il faut toujours saisir le format : yyyymmdd
bonjour Abdou et merci, mais ce n'est pas là qu'est le problème puisqu'avec CAST la finalité est atteinte. Non, le problème, enfin disons le sujet de notre curiosité est, comment se fait-il que la saisie de date suivant le format SQL 92 AAAA-MM-JJ pose un problème à ces SGBD alors qu'au contraire il devrait être celui en posant le moins?
bien sûr on peut passer par des fonctions mais ce n'est pas le propos...
bien sûr on peut passer par des fonctions mais ce n'est pas le propos...
bon ben on en vient à bout...
dans Ocelot, qui est très strictement conforme à SQL 92, la syntaxe suivante passe parfaitement:
INSERT INTO T_SAUCISSE (BOUDIN, MERGUEZ) VALUES ('saucisson à l''ail', DATE '2005-01-01')
_____________________________________________________________________________________________________________
où merguez est un champ DATE
Paradox s'en bat la tête, en tout cas depuis Delphi et sans chercher plus loin. J'en déduis, sans plus m'emm...der, que Paradox n'est pas conforme à SQL92 sur ce point précis, ce qui explique que la syntaxe SQL 92 n'y passe pas.
non mais...
kinder.surprise,
le maton du matou
dans Ocelot, qui est très strictement conforme à SQL 92, la syntaxe suivante passe parfaitement:
INSERT INTO T_SAUCISSE (BOUDIN, MERGUEZ) VALUES ('saucisson à l''ail', DATE '2005-01-01')
_____________________________________________________________________________________________________________
où merguez est un champ DATE
Paradox s'en bat la tête, en tout cas depuis Delphi et sans chercher plus loin. J'en déduis, sans plus m'emm...der, que Paradox n'est pas conforme à SQL92 sur ce point précis, ce qui explique que la syntaxe SQL 92 n'y passe pas.
non mais...
kinder.surprise,
le maton du matou
Juste pour information, j'ai déjà eu un soucis de ce genre sur Oracle. Il confondait les dates anglaises et francaises (uniquement en libellé: Jan, Fev, etc...).
Cela a été corrigé par la modification d'un paramètre dans le fichier d'initiation admin.ora (enfin, celui qui initialise Oracle, je ne me souvients plus de ces détails là).
Bref, à mon avis, le problème Paradox n'est pas unique dans le monde des Bdd. Et la gestion des paramètres régionaux est à revoir.
Cela a été corrigé par la modification d'un paramètre dans le fichier d'initiation admin.ora (enfin, celui qui initialise Oracle, je ne me souvients plus de ces détails là).
Bref, à mon avis, le problème Paradox n'est pas unique dans le monde des Bdd. Et la gestion des paramètres régionaux est à revoir.
Je pourrais le faire juste pour exécuter ma requête mais aprés faut rétablir le type DATE au champ pour le contrôle de DATE ...
Aprés tout j'ai posé une question que je croyais simple, c'est bizarre que jusqu'à maintenant je ne sais toujours pas comment faire, ce genre de PB n'arrive pas souvent, mais quand ça arrive !!!
Merci d'avoir répondu.
Alicia