Bonjour,
dans access 2000, la ligne de code suivante fonctionnait=20
tr=E8s bien: ConvertirDate =3D CVDate(Jour & "." & Mois & "."=20
& Ann=E9e), en retour, par exemple, 15.06.1930.
Dans access 2003, la valeur en retour est 15:06:30 pour=20
autant que l'ann=E9e soit sur 2 digits, sinon erreur de=20
conversion de type. Comment rendre ce code compatible pour=20
une utilisation dans access 2000 et 2003 sans tout=20
re=E9crire ?
D'avance, merci pour votre r=E9ponse.
A+
Jean-Fran=E7ois
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3stone
Salut,
"jean-FrançoisB" dans access 2000, la ligne de code suivante fonctionnait très bien: ConvertirDate = CVDate(Jour & "." & Mois & "." & Année), en retour, par exemple, 15.06.1930. Dans access 2003, la valeur en retour est 15:06:30 pour autant que l'année soit sur 2 digits, sinon erreur de conversion de type. Comment rendre ce code compatible pour une utilisation dans access 2000 et 2003 sans tout reécrire ?
Le point "." n'est pas le séparateur dans les dates!
Utilise plutôt :
ConvertirDate = DateSerial(Annee, Mois, Jour) si Annee, mois et jour sont numérique.
ConvertirDate = CDate(Mois & "/" & Jour & "/" & Annee) si Annee Mois et Jour sont des chaînes.
PS: Il faut éviter de tels noms de champs ou variables car il sont la traduction de Year Month Day qui sont de fonctions d'Access.
-- A+ Pierre (3stone) Access MVP ----------------------------- http://users.skynet.be/mpfa -----------------------------
Salut,
"jean-FrançoisB"
dans access 2000, la ligne de code suivante fonctionnait
très bien: ConvertirDate = CVDate(Jour & "." & Mois & "."
& Année), en retour, par exemple, 15.06.1930.
Dans access 2003, la valeur en retour est 15:06:30 pour
autant que l'année soit sur 2 digits, sinon erreur de
conversion de type. Comment rendre ce code compatible pour
une utilisation dans access 2000 et 2003 sans tout
reécrire ?
Le point "." n'est pas le séparateur dans les dates!
Utilise plutôt :
ConvertirDate = DateSerial(Annee, Mois, Jour)
si Annee, mois et jour sont numérique.
ConvertirDate = CDate(Mois & "/" & Jour & "/" & Annee)
si Annee Mois et Jour sont des chaînes.
PS: Il faut éviter de tels noms de champs ou variables
car il sont la traduction de Year Month Day qui
sont de fonctions d'Access.
--
A+
Pierre (3stone) Access MVP
-----------------------------
http://users.skynet.be/mpfa
-----------------------------
"jean-FrançoisB" dans access 2000, la ligne de code suivante fonctionnait très bien: ConvertirDate = CVDate(Jour & "." & Mois & "." & Année), en retour, par exemple, 15.06.1930. Dans access 2003, la valeur en retour est 15:06:30 pour autant que l'année soit sur 2 digits, sinon erreur de conversion de type. Comment rendre ce code compatible pour une utilisation dans access 2000 et 2003 sans tout reécrire ?
Le point "." n'est pas le séparateur dans les dates!
Utilise plutôt :
ConvertirDate = DateSerial(Annee, Mois, Jour) si Annee, mois et jour sont numérique.
ConvertirDate = CDate(Mois & "/" & Jour & "/" & Annee) si Annee Mois et Jour sont des chaînes.
PS: Il faut éviter de tels noms de champs ou variables car il sont la traduction de Year Month Day qui sont de fonctions d'Access.
-- A+ Pierre (3stone) Access MVP ----------------------------- http://users.skynet.be/mpfa -----------------------------
Jean-FrançoisB
Salut et merci 3stones pour ta réponse.
J'avais effectué plusieurs test sur la manière d'écrire cette ligne de code et je ne suis pas sûr que le séparateur "," soit plus efficace. Par contre, le séparateur " " rend la valeur en retour suivante "15/06/1930" dans access 2003 et erreur avec access 2000. Je n'ai pas encore testé le séparateur "/", mais dans ce cas, je ne comprend plus l'utilité de CVDate!!! Mon problème reste, a savoir que cette application (développée avec access95 et access97, donc elle date!) devrait pouvoir fonctionnée sur des plate-formes différentes sans intervention du développeur. Dans tous les cas, merci pour ces infos. Jean-François.
-----Message d'origine----- Salut,
"jean-FrançoisB" dans access 2000, la ligne de code suivante fonctionnait très bien: ConvertirDate = CVDate(Jour & "." & Mois & "." & Année), en retour, par exemple, 15.06.1930. Dans access 2003, la valeur en retour est 15:06:30 pour autant que l'année soit sur 2 digits, sinon erreur de conversion de type. Comment rendre ce code compatible pour une utilisation dans access 2000 et 2003 sans tout reécrire ?
Le point "." n'est pas le séparateur dans les dates!
Utilise plutôt :
ConvertirDate = DateSerial(Annee, Mois, Jour) si Annee, mois et jour sont numérique.
ConvertirDate = CDate(Mois & "/" & Jour & "/" & Annee) si Annee Mois et Jour sont des chaînes.
PS: Il faut éviter de tels noms de champs ou variables car il sont la traduction de Year Month Day qui sont de fonctions d'Access.
-- A+ Pierre (3stone) Access MVP ----------------------------- http://users.skynet.be/mpfa -----------------------------
.
Salut et merci 3stones pour ta réponse.
J'avais effectué plusieurs test sur la manière d'écrire
cette ligne de code et je ne suis pas sûr que le
séparateur "," soit plus efficace. Par contre, le
séparateur " " rend la valeur en retour
suivante "15/06/1930" dans access 2003 et erreur avec
access 2000.
Je n'ai pas encore testé le séparateur "/", mais dans ce
cas, je ne comprend plus l'utilité de CVDate!!!
Mon problème reste, a savoir que cette application
(développée avec access95 et access97, donc elle date!)
devrait pouvoir fonctionnée sur des plate-formes
différentes sans intervention du développeur.
Dans tous les cas, merci pour ces infos.
Jean-François.
-----Message d'origine-----
Salut,
"jean-FrançoisB"
dans access 2000, la ligne de code suivante fonctionnait
très bien: ConvertirDate = CVDate(Jour & "." & Mois & "."
& Année), en retour, par exemple, 15.06.1930.
Dans access 2003, la valeur en retour est 15:06:30 pour
autant que l'année soit sur 2 digits, sinon erreur de
conversion de type. Comment rendre ce code compatible pour
une utilisation dans access 2000 et 2003 sans tout
reécrire ?
Le point "." n'est pas le séparateur dans les dates!
Utilise plutôt :
ConvertirDate = DateSerial(Annee, Mois, Jour)
si Annee, mois et jour sont numérique.
ConvertirDate = CDate(Mois & "/" & Jour & "/" & Annee)
si Annee Mois et Jour sont des chaînes.
PS: Il faut éviter de tels noms de champs ou variables
car il sont la traduction de Year Month Day qui
sont de fonctions d'Access.
--
A+
Pierre (3stone) Access MVP
-----------------------------
http://users.skynet.be/mpfa
-----------------------------
J'avais effectué plusieurs test sur la manière d'écrire cette ligne de code et je ne suis pas sûr que le séparateur "," soit plus efficace. Par contre, le séparateur " " rend la valeur en retour suivante "15/06/1930" dans access 2003 et erreur avec access 2000. Je n'ai pas encore testé le séparateur "/", mais dans ce cas, je ne comprend plus l'utilité de CVDate!!! Mon problème reste, a savoir que cette application (développée avec access95 et access97, donc elle date!) devrait pouvoir fonctionnée sur des plate-formes différentes sans intervention du développeur. Dans tous les cas, merci pour ces infos. Jean-François.
-----Message d'origine----- Salut,
"jean-FrançoisB" dans access 2000, la ligne de code suivante fonctionnait très bien: ConvertirDate = CVDate(Jour & "." & Mois & "." & Année), en retour, par exemple, 15.06.1930. Dans access 2003, la valeur en retour est 15:06:30 pour autant que l'année soit sur 2 digits, sinon erreur de conversion de type. Comment rendre ce code compatible pour une utilisation dans access 2000 et 2003 sans tout reécrire ?
Le point "." n'est pas le séparateur dans les dates!
Utilise plutôt :
ConvertirDate = DateSerial(Annee, Mois, Jour) si Annee, mois et jour sont numérique.
ConvertirDate = CDate(Mois & "/" & Jour & "/" & Annee) si Annee Mois et Jour sont des chaînes.
PS: Il faut éviter de tels noms de champs ou variables car il sont la traduction de Year Month Day qui sont de fonctions d'Access.
-- A+ Pierre (3stone) Access MVP ----------------------------- http://users.skynet.be/mpfa -----------------------------
.
3stone
Salut,
"Jean-FrançoisB" J'avais effectué plusieurs test sur la manière d'écrire cette ligne de code et je ne suis pas sûr que le séparateur "," soit plus efficace.
Faut relire absolument !!!
Je n'utilise pas la virgule "," comme séparateur... J'utilise au contraire la fonction "DateSerial" qui elle, recoit des arguments séparé par des virgules!!
Par contre, le séparateur " " rend la valeur en retour suivante "15/06/1930" dans access 2003 et erreur avec access 2000.
Ne te laisse pas pas induire en erreur en utilisant les séparateurs liés à tes paramètres régionaux. Préfère l'écriture "US" dans le VBA.
Je n'ai pas encore testé le séparateur "/", mais dans ce cas, je ne comprend plus l'utilité de CVDate!!!
j & "/" & m & "/" & a
crée une *chaîne de caractères* par concaténation mais ne garanti pas qu'elle est comprise comme date! alors que CDate(une chaine) fait cette conversion...
Mon problème reste, a savoir que cette application (développée avec access95 et access97, donc elle date!) devrait pouvoir fonctionnée sur des plate-formes différentes sans intervention du développeur.
Ce n'est pas parce qu'une appli mal faite (ou pour le moins, pas de facon rigoureuse) fonctionne sur une certaine version d'Access et sur une certaine machine, qu'il faut reprocher ces "dysfonctionnement" à Access (ou les croirent inexplicable ;-)
Les beugs ne sont souvent que le fruit d'une erreur de programmation... ou d'interprêtation...
-- A+ Pierre (3stone) Access MVP ----------------------------- http://users.skynet.be/mpfa -----------------------------
Salut,
"Jean-FrançoisB"
J'avais effectué plusieurs test sur la manière d'écrire
cette ligne de code et je ne suis pas sûr que le
séparateur "," soit plus efficace.
Faut relire absolument !!!
Je n'utilise pas la virgule "," comme séparateur...
J'utilise au contraire la fonction "DateSerial" qui elle,
recoit des arguments séparé par des virgules!!
Par contre, le
séparateur " " rend la valeur en retour
suivante "15/06/1930" dans access 2003 et erreur avec
access 2000.
Ne te laisse pas pas induire en erreur en utilisant les
séparateurs liés à tes paramètres régionaux.
Préfère l'écriture "US" dans le VBA.
Je n'ai pas encore testé le séparateur "/", mais dans ce
cas, je ne comprend plus l'utilité de CVDate!!!
j & "/" & m & "/" & a
crée une *chaîne de caractères* par concaténation
mais ne garanti pas qu'elle est comprise comme date!
alors que CDate(une chaine) fait cette conversion...
Mon problème reste, a savoir que cette application
(développée avec access95 et access97, donc elle date!)
devrait pouvoir fonctionnée sur des plate-formes
différentes sans intervention du développeur.
Ce n'est pas parce qu'une appli mal faite
(ou pour le moins, pas de facon rigoureuse)
fonctionne sur une certaine version d'Access
et sur une certaine machine, qu'il faut reprocher
ces "dysfonctionnement" à Access
(ou les croirent inexplicable ;-)
Les beugs ne sont souvent que le fruit d'une erreur
de programmation... ou d'interprêtation...
--
A+
Pierre (3stone) Access MVP
-----------------------------
http://users.skynet.be/mpfa
-----------------------------
"Jean-FrançoisB" J'avais effectué plusieurs test sur la manière d'écrire cette ligne de code et je ne suis pas sûr que le séparateur "," soit plus efficace.
Faut relire absolument !!!
Je n'utilise pas la virgule "," comme séparateur... J'utilise au contraire la fonction "DateSerial" qui elle, recoit des arguments séparé par des virgules!!
Par contre, le séparateur " " rend la valeur en retour suivante "15/06/1930" dans access 2003 et erreur avec access 2000.
Ne te laisse pas pas induire en erreur en utilisant les séparateurs liés à tes paramètres régionaux. Préfère l'écriture "US" dans le VBA.
Je n'ai pas encore testé le séparateur "/", mais dans ce cas, je ne comprend plus l'utilité de CVDate!!!
j & "/" & m & "/" & a
crée une *chaîne de caractères* par concaténation mais ne garanti pas qu'elle est comprise comme date! alors que CDate(une chaine) fait cette conversion...
Mon problème reste, a savoir que cette application (développée avec access95 et access97, donc elle date!) devrait pouvoir fonctionnée sur des plate-formes différentes sans intervention du développeur.
Ce n'est pas parce qu'une appli mal faite (ou pour le moins, pas de facon rigoureuse) fonctionne sur une certaine version d'Access et sur une certaine machine, qu'il faut reprocher ces "dysfonctionnement" à Access (ou les croirent inexplicable ;-)
Les beugs ne sont souvent que le fruit d'une erreur de programmation... ou d'interprêtation...
-- A+ Pierre (3stone) Access MVP ----------------------------- http://users.skynet.be/mpfa -----------------------------
jfb
Re- Tout a fait d'accord. Mais un machin commencé il y a dix ans n'est pas forcément de la meilleur veine quand mes connaissances Access et programmation VBA étaient des plus ...vagues. D'ailleurs c'est toujours le cas, il me semble!! et en plus en lecture je suis nul!! Bon, je m'y remet et je nettoie un peu ce .. Merci a toi 3Stone. A+ JFB
-----Message d'origine----- Salut,
"Jean-FrançoisB" J'avais effectué plusieurs test sur la manière d'écrire cette ligne de code et je ne suis pas sûr que le séparateur "," soit plus efficace.
Faut relire absolument !!!
Je n'utilise pas la virgule "," comme séparateur... J'utilise au contraire la fonction "DateSerial" qui elle,
recoit des arguments séparé par des virgules!!
Par contre, le séparateur " " rend la valeur en retour suivante "15/06/1930" dans access 2003 et erreur avec access 2000.
Ne te laisse pas pas induire en erreur en utilisant les
séparateurs liés à tes paramètres régionaux. Préfère l'écriture "US" dans le VBA.
Je n'ai pas encore testé le séparateur "/", mais dans ce cas, je ne comprend plus l'utilité de CVDate!!!
j & "/" & m & "/" & a
crée une *chaîne de caractères* par concaténation mais ne garanti pas qu'elle est comprise comme date! alors que CDate(une chaine) fait cette conversion...
Mon problème reste, a savoir que cette application (développée avec access95 et access97, donc elle date!) devrait pouvoir fonctionnée sur des plate-formes différentes sans intervention du développeur.
Ce n'est pas parce qu'une appli mal faite (ou pour le moins, pas de facon rigoureuse) fonctionne sur une certaine version d'Access et sur une certaine machine, qu'il faut reprocher ces "dysfonctionnement" à Access (ou les croirent inexplicable ;-)
Les beugs ne sont souvent que le fruit d'une erreur de programmation... ou d'interprêtation...
-- A+ Pierre (3stone) Access MVP ----------------------------- http://users.skynet.be/mpfa -----------------------------
.
Re-
Tout a fait d'accord. Mais un machin commencé il y a dix
ans n'est pas forcément de la meilleur veine quand mes
connaissances Access et programmation VBA étaient des
plus ...vagues. D'ailleurs c'est toujours le cas, il me
semble!! et en plus en lecture je suis nul!!
Bon, je m'y remet et je nettoie un peu ce ..
Merci a toi 3Stone.
A+
JFB
-----Message d'origine-----
Salut,
"Jean-FrançoisB"
J'avais effectué plusieurs test sur la manière d'écrire
cette ligne de code et je ne suis pas sûr que le
séparateur "," soit plus efficace.
Faut relire absolument !!!
Je n'utilise pas la virgule "," comme séparateur...
J'utilise au contraire la fonction "DateSerial" qui
elle,
recoit des arguments séparé par des virgules!!
Par contre, le
séparateur " " rend la valeur en retour
suivante "15/06/1930" dans access 2003 et erreur avec
access 2000.
Ne te laisse pas pas induire en erreur en utilisant
les
séparateurs liés à tes paramètres régionaux.
Préfère l'écriture "US" dans le VBA.
Je n'ai pas encore testé le séparateur "/", mais dans ce
cas, je ne comprend plus l'utilité de CVDate!!!
j & "/" & m & "/" & a
crée une *chaîne de caractères* par concaténation
mais ne garanti pas qu'elle est comprise comme date!
alors que CDate(une chaine) fait cette conversion...
Mon problème reste, a savoir que cette application
(développée avec access95 et access97, donc elle date!)
devrait pouvoir fonctionnée sur des plate-formes
différentes sans intervention du développeur.
Ce n'est pas parce qu'une appli mal faite
(ou pour le moins, pas de facon rigoureuse)
fonctionne sur une certaine version d'Access
et sur une certaine machine, qu'il faut reprocher
ces "dysfonctionnement" à Access
(ou les croirent inexplicable ;-)
Les beugs ne sont souvent que le fruit d'une erreur
de programmation... ou d'interprêtation...
--
A+
Pierre (3stone) Access MVP
-----------------------------
http://users.skynet.be/mpfa
-----------------------------
Re- Tout a fait d'accord. Mais un machin commencé il y a dix ans n'est pas forcément de la meilleur veine quand mes connaissances Access et programmation VBA étaient des plus ...vagues. D'ailleurs c'est toujours le cas, il me semble!! et en plus en lecture je suis nul!! Bon, je m'y remet et je nettoie un peu ce .. Merci a toi 3Stone. A+ JFB
-----Message d'origine----- Salut,
"Jean-FrançoisB" J'avais effectué plusieurs test sur la manière d'écrire cette ligne de code et je ne suis pas sûr que le séparateur "," soit plus efficace.
Faut relire absolument !!!
Je n'utilise pas la virgule "," comme séparateur... J'utilise au contraire la fonction "DateSerial" qui elle,
recoit des arguments séparé par des virgules!!
Par contre, le séparateur " " rend la valeur en retour suivante "15/06/1930" dans access 2003 et erreur avec access 2000.
Ne te laisse pas pas induire en erreur en utilisant les
séparateurs liés à tes paramètres régionaux. Préfère l'écriture "US" dans le VBA.
Je n'ai pas encore testé le séparateur "/", mais dans ce cas, je ne comprend plus l'utilité de CVDate!!!
j & "/" & m & "/" & a
crée une *chaîne de caractères* par concaténation mais ne garanti pas qu'elle est comprise comme date! alors que CDate(une chaine) fait cette conversion...
Mon problème reste, a savoir que cette application (développée avec access95 et access97, donc elle date!) devrait pouvoir fonctionnée sur des plate-formes différentes sans intervention du développeur.
Ce n'est pas parce qu'une appli mal faite (ou pour le moins, pas de facon rigoureuse) fonctionne sur une certaine version d'Access et sur une certaine machine, qu'il faut reprocher ces "dysfonctionnement" à Access (ou les croirent inexplicable ;-)
Les beugs ne sont souvent que le fruit d'une erreur de programmation... ou d'interprêtation...
-- A+ Pierre (3stone) Access MVP ----------------------------- http://users.skynet.be/mpfa -----------------------------
