FORMAT DE DATE SYSTEM ET PORTABILITÉ
cs_DARKSIDIOUS
Messages postés
15814
Date d'inscription
jeudi 8 août 2002
Statut
Membre
Dernière intervention
4 mars 2013
-
29 juin 2007 à 15:47
pillsmen Messages postés 27 Date d'inscription samedi 27 mai 2006 Statut Membre Dernière intervention 3 juillet 2007 - 3 juil. 2007 à 13:24
pillsmen Messages postés 27 Date d'inscription samedi 27 mai 2006 Statut Membre Dernière intervention 3 juillet 2007 - 3 juil. 2007 à 13:24
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/43286-format-de-date-system-et-portabilite
https://codes-sources.commentcamarche.net/source/43286-format-de-date-system-et-portabilite
3 juil. 2007 à 13:24
Merci encore Renfield
3 juil. 2007 à 11:16
3 juil. 2007 à 11:14
Unicode, moyena l'époque.
bien que VB stockes en interne, les string en Unicode, les parametres de type String sont retransformés en ASCII lors des appels aux APIs
StrPtr nous donne l'adresse de la chaine, ce qui interesse finallement l'API, qui n'y voit que du feu...
seulement, le parametre n'est plusun String, VB laisse la chaine en Unicode
(note le W dans le nom de l'API)
3 juil. 2007 à 11:07
Par curiosité quel est le rôle de la fonction StrPtr(..) ? je n'ai pas trouvé dans l'aide ds VBA.
Pendant que j'y suis :p, j'ai encore un p'tit problème avec les dates.
J'ai créé et posté sur ce site 2 formulaires access de calendriers entièrement gérés par labels (pas d'APIs). Je pense que la gestion des dates doit aussi y être catastrophique que ce que j'avais fait précédemment pour cette source!
http://www.vbfrance.com/codes/CALENDRIER-SEMAINE-VBA-ACCESS_42640.aspx
http://www.vbfrance.com/codes/CALENDRIER-MOIS-VBA-ACCESS_42460.aspx
Le problème c'est que je dois générer une date à partir de variables (une pour le jour, une pour le mois, une pour l'année). Je le fesait grâce à la fonction cdate style cdate(num_jour & "/" & num_mois & "/" & num_annee) mais le code n'est, par conséquent, pas portable.
(je voulais le faire notamment pour cette source afin d'initialiser la table avec des dates aléatoires)
A ce jour, la solution que j'ai trouvé serait d'utiliser une variable représentant le nombre de jours entre la date désirée et la date actuelle et de généré la date au format "local" avec dateadd(...). Je ne sais pas si c'est la bonne solution, ou s'il en existe une meilleur en jouant sur la fonction Format(...).
Une idée ? :)
3 juil. 2007 à 09:27
les controles de Access le gèrent.
Private Declare Function GetLocaleInfo Lib "kernel32.dll" Alias "GetLocaleInfoW" ( _
ByVal locale As Long, _
ByVal lctype As Long, _
ByVal lplcdata As Long, _
ByVal cchdata As Long _
) As Long
et dans le code :
nretval = GetLocaleInfo(locale, type_retour, StrPtr(lplcdata), cchdata)
3 juil. 2007 à 08:57
3 juil. 2007 à 08:54
2 juil. 2007 à 16:05
gaffe a l'API, elle renvoie des fois des choses particulières... des \t ou autres.
concernant mon soucis que j'avais eu, en fait, j'ai du changer mes parametres regionnaux une fois l'appli lancée... et le label ne c'eait pas mis a jour.
2 juil. 2007 à 16:01
2 juil. 2007 à 16:00
La raison est simple :
Dans le cas du format de date fr : dd/mm/yyyy si contrôle il y a, la saisie de 09/02/07 ne fonctionnerait pas alors que ça simplifie grandement la saisie...
Aprés tout, si l'utilisateur décide d'utiliser un autre format que celui qui lui est signalé, c'est à ses risques ;)
2 juil. 2007 à 11:24
Si on est le 2 Février 2007, pas de problème, par contre comme tu dis si il a correspondance entre deux (ou les trois) des trois parties (jour, mois et année) il s'arrètera dans l'ordre sur dd, mm.
Le truc c'est que j'aimerais utiliser les API le moins possible, mais je crois que c'est la seule solution à mon problème ;)
2 juil. 2007 à 10:38
donc ok, ta solution fonctionne. évite les transtypage, mais ca roule
par contre, TRES dangereux de detecter le format de date de la sorte...
07.07.07 => dd/dd/yyyy
utilises plutot les APIs pour retrouver directement le format
2 juil. 2007 à 10:30
Admettons d'avoir les paramètres régionnaux pour le format date courte : yyyy.mm.dd. (format hongrois, me demander pas pourquoi, c'est le premier format "bizarre" que j'ai trouvé ^^). Si je saisie une date dans un format complètement différent il me sauvegarde n'importe quoi dans la BDD ?!
J'ai tester en entrant un format jj/mm/yyyy (pour exemple : 09/02/2007, en gardant le format system hongrois), quand je consulte la base de donnée, il me met 2007.09.02 !
Autrement dit, si l'utilisateur saisie une date dans un format autre que le format système, si ce format est "proche" du format système, pas de problème (style dd/mm/yyyy et dd.mm.yyyy) mais dans le cas contraire ..... ce qui implique qu'il faudrait une vérification sur le format à l'insertion histoire d'être sûr ?!
2 juil. 2007 à 09:53
je modifie la source de suite :).
Par contre Renfield, je crois que tu n'as pas saisi le principe de mon label :).
A l'ouverture du formulaire, la fonction ReturnFormat() permet de construire la chaîne de caractère (masque de saisie) qui indiquera à l'utilisateur sous quel format entrer la date par analyse de la date renvoyée par la fonction Date(). Celui-ci est donc basé sur les paramètres régionnaux (j'ai testé avec tout les formats de dates que j'avais dans Panneau de configuration > Options régionnales et linguistiques). Je n'ai trouver aucune source qui le fasse, c'était donc l'intérêt de celle-ci ;).
En revanche, dans mon programme je devrais gérer l'insertion/lecture de dates quelque soit la région donc si j'ai bien compris en changeant mes requêtes mon code sera portable quelque soit les paramètres régionnaux du système?
Quelle misère cette gestion des dates sous Access ... ;)
29 juin 2007 à 16:04
ce qu'indique DarkSidious est vrai, tu fait faire trop de transtypages, qui risque de ralentir la chose... présentement, Access va s'y retrouver, mais bon.
29 juin 2007 à 16:00
tu as fait tout ce qu'il ne faut pas faire, au contraire.
c'est un sujet qui m'est cher, et ton code ne va pas.
les manipulations de dates en SQL se font comme cela :
"INSERT INTO test (date_test) VALUES (#" & Format$(date_test.Value,"MM\/DD\/YYYY") & "#);"
on s'affranchit au plus tôt des parametres regionnaux.
comme nous y invite ton interface, j'ai saisi 02/09/2007
(deux septembre 2007)
mais ton code :
"INSERT INTO test (date_test) VALUES ('" & CDate(date_test.Value) & "');"
execute
... VALUE('02/09/2007')
qui sera interpreté par Access, via les parametres regionnaux...
bonjour le 9 février ^^
on ne force jamais un format de saisie à l'utilisateur, le programme doit s'adapter aux parametres regionnaux.
pour ta recherche, idem...
request = "SELECT Count(1) AS Nb " & _
"FROM test " & _
"WHERE test.date_test=#" & Format$(date_recherche.Value,"MM\/DD\/YYYY") & "#;"
et c'est TOUT....
Access reconnaitra une date, passée en format internationnal, parfaitement compris, quelles que soient les parametres regionnaux
29 juin 2007 à 15:47
"INSERT INTO test (date_test) VALUES ('" & CDate(date_test.Value) & "');"
Les dates en SQL access doivent être entourées de dièses et être au format américain... à moins que tu ne l'enregistre dans un champ de type texte, mais là c'est pas très optimisé !
DarK Sidious