GESTION DES CODE POSTAUX AVEC UNE BASE ACCESS
yvessimon
Messages postés
637
Date d'inscription
mardi 22 avril 2003
Statut
Membre
Dernière intervention
9 janvier 2017
-
17 nov. 2010 à 14:51
JamaiSsS Messages postés 1 Date d'inscription lundi 20 décembre 2010 Statut Membre Dernière intervention 20 décembre 2010 - 20 déc. 2010 à 15:20
JamaiSsS Messages postés 1 Date d'inscription lundi 20 décembre 2010 Statut Membre Dernière intervention 20 décembre 2010 - 20 déc. 2010 à 15:20
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/52484-gestion-des-code-postaux-avec-une-base-access
https://codes-sources.commentcamarche.net/source/52484-gestion-des-code-postaux-avec-une-base-access
20 déc. 2010 à 15:20
24 nov. 2010 à 23:21
C'est en mars 2011 que Mayotte deviendra le 101 ème déparement.
Laissons à l'INSEE et LAPOSTE le temps de réagir!!
(les paris sont ouverts pour savoir qui sera à jour en premier!!)
Mais restons dans le sujet : le code proposé par Alex
Moi je l'encourage et suis à sa disposition s'il souhaite s'orienter ou tester d'autres types de bases de données.
Pour ma part je reste prudent sur des applications type Code Postal alors que ce code n'est pas rendu public, gratuitement, par LAPOSTE.
Personnellement je gère, pour des applications généalogique et de localisation géographique sur Google ou l'IGN, les communes par leur code INSEE et je mets à jour le code postal en fonction de ce que je peux obtenir! (D'autant qu'en ce moment LAPOSTE introduit de nombreuses modifications pour faire face à la concurrence et se rapproche d'une norme plus 'logique'. En particulier pour les communes, dont j'ai parlé précédemment, qui dépendent d'un centre de distribution situé dans un autre département ils sont en cours de leur modifier leur code postal pour que celui-ci respecte leur véritable département d'appartenance).
Pour compléter mon exemple précédent:
EOURRES Code Postal 26560 dans pratiquement toutes les bases de données des Codes Postaux n'est pas une commune de la Drôme mais des Hautes Alpes, code INSEE 05047
LAPOSTE vient de modifier son code postal en lui attribuant 05300
Il y a longtemps que LAPOSTE aurait du comprendre que l'identification des communes et les problèmes de routage du courrier sont deux choses différentes.
L'identification n'est pas du ressort de LAPOSTE et c'est la seule chose que tout un chacun doit connaitre et connaitre gratuitement.
Le problème de routage du courrier est un problème strictement interne et c'est à eux de faire le nécessaire.
Résultat: il est aujourd'hui très facile de faire des programmes de recherche de communes à partir de leur code INSEE ou vice versa.
Faire la même chose sur le code postal c'est la galère! Merci LAPOSTE.
Pierre
24 nov. 2010 à 20:41
il ne manque plus qu'à rajouter le 101 ème départment français (Mayotte) avec ses 17 communes incluant 19 cantons
JR
24 nov. 2010 à 12:33
Mais si je m'en réfère au titre du code ( GESTION DES CODE POSTAUX AVEC UNE BASE ACCESS ), il s'agit bien de gérer des codes postaux.
On peut donc penser, il me semble, que ce besoin soit dicté par la nécessité de travailler sur des données postales actualisées.
Il reste, bien sûr, que la méthode employée est digne d'intérêt pour son aspect pédagogique et j'en remercie l'auteur et je l'encourage.
Pour d'autres besoins, plus 'géographiques', il existe d'autres fichiers. Par exemple :
http://www.pillot.fr/cartographe/fichiers.php
23 nov. 2010 à 23:35
Rassures-toi je ne vais pas polémiquer entre l'INSEE et LAPOSTE!
Les deux répondent à des besoins totalement différents:
L'INSEE recense les communes de manière unique (y compris sur le plan historique depuis sa création). Il est normal que les mises à jour soient peu fréquentes puisque ça ne concerne que des nouvelles communes ou des fusions de communes.
LAPOSTE a inventé une codification pour son seul besoin : l'acheminement du courrier et elle fait évoluer cette codification en fonction de ses propres besoins. D'où le risque à utiliser cette codification pour autre chose, comme malheureusement trop d'applications le font.
Le plus aberrant, à mon avis, c'est que l'on demande aux particuliers de normaliser les adresses sur leur courrier et ce, avec une norme en évolution permanente et dont on fait payer les évolutions!
Aujourd'hui on trouve de nombreuses applications gratuites sur le net permettant de retrouver un code postal. Or toutes ont une base de données fausse (y compris celle jointe à ce programme, et ce n'est pas une critique à son auteur dont j'apprécie et encourage les efforts).
Le seul moyen d'avoir gratuitement un code postal est d'interroger le site de la poste : http://www.laposte.fr/Particulier/Utilisez-nos-outils-pratiques/Outils-et-documents/Trouvez-un-code-postal
Mais il faut le faire au coup par coup et pas moyen de télécharger un fichier complet (et pour cause il est payant!).
Il va falloir se pencher sur le problème d'interroger le site de la poste depuis une application.
Quand aux applications autres que le courrier je ne peux que les encourager à utiliser les codes INSEE. C'est ce qui est, de plus en plus, utilisé par les applications à caractère géographique et généalogique par exemple.
Amicalement,
Pierre
23 nov. 2010 à 23:11
Et puis Dixit Alex
"Delphi, enfin c'est une autre histoire.
Si vous avez des améliorations pour cette source, je suis à votre écoute."
Un : Code commenté.
Deux : Code en Delphi (pascal)
Trois : Code structuré en plusieurs unités
Quatre : Notions de base de données
Moi je note.
23 nov. 2010 à 22:46
Ya que deux postiers. Cantador and CariBensila.
Fo attendre la timbre du bon programmeur.
Je plaisante, mais quand même . Heu même si il à plus de queue (file de la poste) les casquettes sont toujours la ???
Moi perso je ne vois personne comme client depuis des mois ben je me courbe.
Amitiés quand même à tous.
23 nov. 2010 à 09:08
"que l'INSEE ne fait une mise à jour des fichiers téléchargeables qu'une fois par an."
Oui, mais c'est l'INSEE du coup, qui n'est pas à jour..
Autrement dit, il faut aller les chercher sur le site de La Poste qui les met à jour
mensuellement, mais le fichier Hexaposte n'est pas gratuit à ma connaissance.
22 nov. 2010 à 22:19
Encore une petite précision:
Attention à l'utilisation de l'information DEPARTEMENT à partir du Code Postal.
Dans un certain nombre de cas le Code Postal est attribué en fonction du Bureau de Distribution. Pour certaines communes en limite du département le code peut-être celui du département voisin. Seul le code INSEE peut permettre de déterminer le département d'une commune. Un exemple:
EOURRES Code Postal 26560 n'est pas une commune de la Drôme mais des Hautes Alpes, code INSEE 05047
Cordialement,
Pierre
22 nov. 2010 à 18:07
Pour info :
http://www.laposte.fr/sna/rubrique.php3?id_rubrique=40
22 nov. 2010 à 16:59
Juste un petit point.
Attention aux codes INSEE dans ta base.
Pour les départements 1 à 9 le code département a été pris à 1 .. 9 au lieu de 01 ... 09
Probablement un champ pris en numérique au lieu de texte lors de l'import.
Attention aussi au cas particulier de la Corse : 20, 2A, 2B
Cordialement,
Pierre
22 nov. 2010 à 13:17
Juste quelques précisions ou avis personnel.
Bien sur il est possible d'utiliser Access, Excel ou même des fichiers texte en CSV.
Concernant Paradox une précision concernant la remarque 'Paradox ne contient évidement pas plusieurs tables'. En fait pour Paradox la base de données est le répertoire et chaque fichier .DB est une table.
Concernant la mise à jour à partir du site INSEE c'est une très bonne idée mais sans doute n'est-il pas nécessaire de le faire à chaque lancement pour ne pas allonger le temps de lancement du programme. Une vérification périodique doit être suffisante. Je crois même me souvenir que l'INSEE ne fait une mise à jour des fichiers téléchargeables qu'une fois par an.
Un avis personnel: Avec des tables comportant un très grand nombre d'enregistrements ces solutions peuvent ne pas être très performantes pour des accès SQL.
Il existe de 'véritables' logiciels de bases de données gratuits (OracleXE, FireBird ....) pour lesquels on trouve des composants Delphi très performants. Ceci permets de disposer d'un langage SQL beaucoup plus riche pour des requêtes complexes ainsi que des procédures cataloguées .... Et d'éviter aussi les limitations du nombre de lignes dans certaines versions d'Excel. Pour ma part j'utilise OracleXE pour une base contenant les coordonnées et caractéristiques des villes et autres points du monde à partir des fichiers du site GNS (http://earth-info.nga.mil/gns/html/cntry_files.html). Pour certains pays ce sont plusieurs centaines de millier de points qui sont répertoriés.
Cordialement,
Pierre
19 nov. 2010 à 19:44
oui il serrait alors intéressant d'utiliser Excel car sur le site de l'INSEE, le fichier disponible est au format Excel, je vais corriger cela et même voir pour télécharger automatiquement le fichier. mise à jour à suivre ...
merçi pour votre note.
Je voulais aussi rectifier une erreur dans mon poste précédant Paradox ne contient évidement pas plusieurs tables, j'ai été un peu vite pour écrire !
cordialement
Alex
19 nov. 2010 à 14:34
Le code n'appelle pas beaucoup de commentaires si ce n'est
qu'il vaut mieux éviter de coder après un next dans une boucle While.
Par ailleurs, je te conseille de préférer les requêtes SQL paramétrées, beaucoup plus faciles
à écrire.
Enfin, sur le sujet des codes postaux, le hic est qu'il sont sujets à de nombreuses modifications.
Ce qui serait en revanche intéressant est de sniffer en ouverure du programme les infos de la page INSEE en question et de télécharger les code postaux dans ta base.
Voilà, en tout un cas un bon début.. (7/10)
bon courage pour la suite
19 nov. 2010 à 12:16
Oui, Biensure, il est évident qu'on peut mettre plusieurs tables différente avec access, paradox, mysql et d'autre base de donné que je ne nommerais pas, mais pour içi j'ai préféré dissocié la table client et la table code postal par facilité, comme ceci je peux l'utiliser dans d'autre application sans devoir trop me compliquer la vie, je suis un peu faignant et donc je préfère simplifier les manipulations mais peut être que çà peut ralentir l'application, (c'est possible, à vous de me le dire), si c'est le cas alors il faudrait faire une mini application qui créera une Table à la première utilisation du logiciel et insèrera automatiquement toutes les données de la table CodePostal (avec des requète SQL: INSERT par exemple), à voir... il y a quand même + de 38000 Code Postaux à encoder.
Enfin si ce n'est pas ce que tu voulais dire Yvessimon, désolé je n'ai pas compris ta démarche.
Cordialement
Alex
19 nov. 2010 à 10:45
Une base ACCESS ou EXCEL peut contenir plusieurs tables.
Ces table sont sélectionnable avec ADO et SQL
Ceci permet d'avoir un seul fichier de base de donnée
Salutations
18 nov. 2010 à 21:17
Je pense que oui mais j'ai pas encore approfondi la question, cependant je vais étudier ce qu'on peut faire avec des Fichiers Excel car j'ai le projet de faire avec cette source de calculer la distance entre le domicile d'un représentant et le code postal de son Client pour en calculer les frais ect... . J'avais penser utiliser une feuille Excel pour renseigner les Km en 2 codes postaux mais j'explore aussi une autre piste pour récuperer les info sur le net (avec mappy ou autre) mais j'en suis pas encore là, c'est compliqué... J'apprend tout juste les codes Delphi, enfin c'est une autre histoire.
Si vous avez des améliorations pour cette source, je suis à votre écoute.
Merçi
Bon courage à tous
Alex
17 nov. 2010 à 14:51
Avec une base excel c'est possible
Bon travail