TOUT PETIT PB DE SYNTAXE (SQL)
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.
12 réponses
Résumé de la discussion
Problème : en ANSI SQL-92, l'affectation d'une valeur de type date échoue lors d'une mise à jour, en raison d'un formatage de 31/12/2001 et d'erreurs de type. Plusieurs solutions existent : utiliser des littéraux DATE conformes au standard, par exemple DATE '2001-12-31', ou employer des fonctions de conversion comme TO_DATE('31/12/2001','DD/MM/YYYY'); cependant certaines bases non conformes exigent des ajustements régionaux. D'autres systèmes, tels que Paradox ou Interbase, ne suivent pas SQL:92 pour les littéraux de date, ce qui peut expliquer les erreurs et nécessite une approche adaptée selon le SGBD. En pratique, la gestion des formats et des paramètres régionaux peut influencer le comportement, et certains systèmes exigent des paramètres supplémentaires ou des réglages initiaux pour une interprétation correcte.
-
Tu mets la valeur de type chaîne de caractère et tout fonctionnera.
-
Ouiiiiiiii ça je le sais, mais tu sais aussi que c'est une solution temporaire.
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
-
-
essay de mettre la valeur de la date entres dieze ex #31/12/20001#
-
IL FAUT ECRIRE LA DATE COMME SUIT ANNEEE-MOIS-JOUR
EXP: 2002-01-06 ok -
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..... -
au fait, si tu nous disais de quel SGBD il s'agite?
-
-
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 (-: -
@Utilisateur anonymeMerci, TOI ... BON J y vais tout de suite.
Au fait, j'ai vu que tu m'a répondu à 1H Du MAT ...
A cette heure si tu devrais dormir. Alors Repose toi Kinder, Le sommeil est important (Sincèrement ...)
Amicalement,
Alicia. -
@Utilisateur anonymebou! à 1 h du mat je suis en plein boulot, moi! sauf fatigue exceptionnelle... le couvre-feu c'est plutôt 5 H du matin...
mais t'inquiète, je dors le matin (-:
il t'a répondu? -
@Utilisateur anonymeça y ai ... Je vais péter les plombs ... J'éteins tout je sors prendre de l'air dans l'aire ...
J'ai utilisé toutes les combinaisons pour inscrire une valeur de type date sous PARADOX 7. Et il y a toujours le fameux Type mismatches.
J'aurais du faire Psychologue ..
-
-
salut,
et ca??
update <ta_table> set <ton_champs>=to_date('31/12/2001','DD/MM/YYYY');
Steph -
ContributeurN'oublies pas les ##qui encadrent la date, je pense que si je ne me trompe, c'est coe ça :
#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 -
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...-
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.
-
-
(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-
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.
-
-
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-
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...
-
-
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-
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. -
-
-
