Mise à jour d’une base Access par fichier CSV ou Excel – Episode 1

Passerelles Access CSV

A partir de fichiers CSV ou de fichiers Excel, comment appliquer des mises à jour à ma base de données Access ? A savoir : ajouter de nouveaux enregistrements dans une table, et modifier les enregistrements existants ?

Scénario

Fichier CSVTout est dans l’introduction : l’idée est de gérer des mises à jour de la base de données à partir de fichiers CSV ou Excel, le plus simplement possible bien sûr. La question est assez simple… mais la solution un peu moins ! On va donc démarrer une (looongue) série d’articles sur le sujet.

Dans cet article, pas de VBA, ça viendra par la suite !  Aujourd’hui, nous allons seulement définir les règles du jeu.

Note
Il sera impossible de résoudre tous les cas de figure et de répondre aux besoins de tous : l’objectif est de fournir un outil suffisamment générique. Si vous avez des cas particuliers, ou si vous détectez des bugs, postez vos commentaires par ici !

Voici donc le scénario qui sera suivi dans les prochains articles :

  1. On souhaite mettre à jour une table (une pour l’instant, on peut imaginer plus ultérieurement).
  2. Les données de mise à jour sont fournies dans un fichier CSV, parce que c’est un format simple à manipuler. Et aussi parce que de nombreuses personnes produisent ou retouchent leurs données CSV dans Excel, avant de les basculer dans Access. Optionnellement, on pourra aussi utiliser une liste au format Excel natif. Dans ce qui suit, je parle plutôt de fichiers CSV, mais j’ai prévu un exemple plus tard, sur des fichiers .xls ou .xlsx.
  3. Chaque ligne du fichier source décrit une opération de mise à jour. Il peut s’agir d’une création de nouvelle ligne dans la table cible, ou d’une mise à jour de ligne existante. On ne gèrera pas (pour l’instant en tout cas) les suppressions.
  4. Les données fournies dans le fichier source doivent être compatibles avec la table. En d’autres termes, si un champ est numérique dans la table, le fichier CSV ne doit pas fournir une valeur texte.
  5. L’ordre des colonnes n’a pas d’importance dans le fichier source (les colonnes de ce fichier ne sont pas obligées d’être dans le même ordre que les colonnes de la table).
  6. Le fichier source n’a pas obligatoirement toutes les colonnes de la table. Par contre, si des lignes doivent être créées dans la table, toutes les colonnes obligatoires doivent bien sûr figurer dans le CSV.
  7. La clef primaire doit être présente dans le fichier CSV (c’est elle qui permettra d’identifier les lignes à mettre à jour).
  8. La table aura une clef primaire simple (faite d’un champ uniquement), et non pas composée (faite de plusieurs champs). C’est une restriction voulue pour l’instant pour ne pas charger le code. Si vous avez besoin d’une clef composée, adaptez le code VBA fourni ! 😉
  9. Le fichier CSV pourra avoir plusieurs formats (par exemple : un délimiteur « , » ou un délimiteur « ;« ).

La table d’exemple

La table qui servira pour cet exemple est très simple : on suppose qu’il s’agit d’une table de destinataires de newsletter. Chaque destinataire est caractérisé par un numéro automatique (Id), un nom, un prénom et un email. La table est vide au départ de mon scénario, mais c’est un détail.

Table des destinataires de newsletter

Le fichier CSV d’exemple

L’objectif est d’ajouter – ou de mettre à jour – des lignes de la table tbl Destinataires Newsletter ci-dessus, à l’aide d’un fichier CSV. Voici le fichier CSV de test (vous remarquez que certains champs ne sont pas renseignés) :

Id,Prénom,Nom,Email
8,Han,Solo,han.solo@rebels.com
9,Hervé,Inisan,webmaster@self-access.com
10,Luke,Skywalker,
11,Anakin,Skywalker,anakin.skywalker@darkstar.com
12,R2,D2,

A terme, l’idée est de pouvoir injecter autant de fichiers CSV que nécessaire dans la base de données… mais ça, ce sera après ! 😉

Vous aimerez aussi...

2 réponses

  1. Hervé Inisan dit :

    Christophe VDW > L’échange de données par mail pour synchroniser une base de données n’est pas « fluide », et peut être source de problèmes.

    Une première chose : ne jamais utiliser de champs NuméroAuto dans ce genre de scénario. Sinon, 2 utilisateurs peuvent créer des enregistrements portant le même numéro à un instant quelconque, et la synchronisation tombe par terre aussitôt. Les clefs primaires doivent être des numéros uniques, toutes machines confondues.

  2. Christophe VDW dit :

    bonjour
    Merci pour tous vos article très claire!!!!!
    mon problème est « l’utilisation » d’une même base ACCESS par deux utilisateur différent :
    (2 PC pas en réseau et pas connecté par internet en continu)

    Une base d’export CSV puis envois D’un MAIL puis une base mise a jour:
    est-ce la meilleur solution pour harmonisé les table en fin de journée?

    Comment faire POUR NE PAS AVOIR DE DOUBLONS EN CLEF PRIMAIRE?
    (si les utilisateur créent des lignes chaque-un de leur coté)

    Comment faire pour les suppressions de lignes?

    merci pour vos  » conseils « 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *