Accueil «Pascal
Cambier»
mdb2js
Procédures VBA pour exporter des données MS-Access en tableaux (array)
JavaScript, ainsi que la création de quelques fonctions pour exploiter
ce(s) array
mdb 2 js : le 2 étant un "to" anglophone (vers)
Il ne s'agit pas d'un programme client/serveur, mais uniquement d'un
programme CLIENT.
Avertissements
Il n'est pas dans mes intentions de faire un cours
- de Visual Basic Application for ACCESS;
- de JavaScript;
- d'Access et de gestion de bases de données.
Vous êtes donc sensés avoir un bon minimum de bases dans ces trois
matières. Le code VBA est, il me semble, suffisamment documenté.
L'utilisation de MDB2JS ne me rend responsable en rien du tout. Le
produit est livré tel quel.
Téléchargement
mdb2js est un ensemble de codes VBA créant des routines JS. Il est
évident que toute contribution (amélioration du code, ajout de
fonctionnalités, ...) ne sera répercutée que si vous m'en faites part...
Avis aux webmasters et aux diffuseurs
La gratuité ne veut pas dire que vous pouvez diffuser ce programme sans
mon autorisation.
Veuillez donc me contacter avant de placer
l'exécutable au sein de votre site ou de votre CD-ROM
Par contre, vous pouvez tout à fait librement faire référence directe à
cette page.
Pascal Cambier
|
Mode d'emploi
La base de données "mdb2js.mdb" contient une table avec un vieux
glossaire qui servira pour l'exemple. Une macro "autoexec" ouvre
directement un formulaire contenant un bouton de commande lançant la
procédure d'exportation (en VBA).
Cette procédure demande d'abord le dossier (répertoire) où vous
allez
exporter les données. Une fois un dossier sélectionné, le bouton "OK"
est activé
Ensuite, elle demandera si vous désirez exporter les tables, nous
verrons plus loin que ce n'est pas recommandé.
En fait, il vaut mieux créer des requêtes réservées à cet usage.
Elles auront pour préfixe "RJS".
Une fois les données exportées (c'est pas instantané, mais c'est
très
rapide), un petit message vient vous avertir que tout est fini
Les données sont alors disponibles dans autant de fichiers qu'il y
a de tables et/ou requêtes.
Pour utiliser le code dans une autre base, vous avez différentes
possibilités suivant vos compétences ou vos affinités :
- Le copier/coller du code VBA vers votre base;
- L'importation :
- des modules et l'appel de la procédure adéquate par vos
soins;
- des modules et du formulaire;
- des précités et de la macro 'autoexec';
- ...;
- de la mise en oeuvre d'une solution plus pro (macro
complémentaire, ..) que je vous invite à me communiquer.
Conventions
Si le mode d'emploi est assez simple, le fonctionnement des procédures
tient compte de conventions importantes dans la construction de la base
de données, plus exactement dans la préparation à l'exportation.
Les tables
Les tables dans Access contiennent les données "brutes", pas souvent
dans l'ordre souhaitable. Vous pourriez aussi y avoir des données non
nécessaires à votre application WEB.
De plus, pour l'exploitation des données, il faut des fonctions et on
ne peut pas en préparer autant que l'on pourrait trouver de cas de
figure. Enfin, il faut aussi limiter la masse parce qu'elle doit être
entièrement téléchargée pour être exploitable : il
ne s'agit pas d'une interrogation à distance, toutes les données sont
transférées chez le client !
Je conseille donc de ne pas exporter les tables, bien que j'en laisse
le choix.
Les requêtes
Si toutes les tables sont exportables d'une pièce, ce n'est pas
le cas des requêtes où j'ai décidé que seules celles dont le nom
commence par "RJS" seront prises en compte. Autrement dit, vous n'avez
pas à modifier
la structure intime de votre base, il suffit d'ajouter les requêtes qui
sélectionneront les enregistrements et champs, trieront dans l'ordre
voulu, calculeront éventuellement.
L'exportation de requêtes "Rjs" aura pour premier effet de créer un
fichier ayant le même nom SANS le "Rjs". Il pourrait donc y
avoir confusion/écrasement entre une table nommée "glossaire" et une
requête nommé "RjsGlossaire", la dernière prenant la place de la
première.
La casse / syntaxe
La casse (CAPITALES / minuscules) ayant son importance en JavaScript,
il a été décidé une uniformisation
arbitraire que vous découvrirez au fur et à mesure des noms utilisés en
accentuant en gras la ou les lettres
capitales.
Le premier champ
Le premier champ est logiquement trié. Ceci dit, il y a des différences
entre la logique VBA et JS, mais, à ce stade
cette logique n'est pas interférente avec les fonctions JS utilisées.
Disons que VBA est plus "humain" que "JS"... (ce qui fera sourire
certains...)
Le premier champ servira aussi à la fonction de recherche dans une
liste déroulante qui, après sélection, affichera
le(s) correspondance(s) dans des zones de texte "formulaire"
L'exploitation
Fichiers JavaScript (.js)
Dans l'exemple fourni, seule la requête "RjsGlossaireTrie" sera
exportée vers le fichier
"Glossairetrie.js". Remarquez que "Rjs" a disparu et que la
casse à été modifiée.
Documentation HTML (DocExportJs.html)
Pour l'ensemble des tables/requêtes exportées, il y a un fichier HTML
appelé "DocExportJs.html" placé dans le dossier
d'exportation.
Entre ses balises <HEAD> et </HEAD>, vous trouverez autant
de lignes similaires à la suivante qu'il n'y a de fichiers (tables)
exportés : <Script language="Javascript" src="Glossairetrie.js"></script>
Ce document "DocExportJs.html" contient toute
la "documentation" HTML à copier/coller dans vos propres fichiers.
La table JS Array
La table/requête est exportée dans le tableau (array) du même nom que
le fichier .js. Ainsi, si la requête se nomme RjsGlossaireTrie, l'array
JS
se nommera Glossairetrie. Si vous exportez les tables et les
requêtes, faites attention aux noms : une table "Glossaire" sera
écrasée par une requête "RjsGlossaire", le "Rjs" étant éliminé.
Cette table est exploitée par une fonction/objet dont le préfixe est
"Ary". La requête "RjsGlossaireTrie" est exploitable par la
fonction "AryGlossairetrie" et ses propriétés que
sont les noms de champ
Le formulaire "Frm...Recordset..."
Les fonctions écrites par MDB2JS sont exploitables par autant de
formulaire HTML que de RecordSet comme montré dans "DocExportJs.html"
Le nom des formulaires vient de la table/requête. À une requête nommée "RjsGlossaireTrie",
il y aura un
formulaire HTML nommé "FrmGlossairetrie"
Dans ce formulaire, il y a une liste déroulante basée sur le nom du
premier champ de la table/requête. L'action engagée par un clic sur
cette liste appelle une fonction procédure "ToutEcrireFrmGlossairetrie()"
qui appelle elle-même toutes les fonctions attachées à un champ. Dans
l'exemple livré, il n'y a que deux champs exportés. Cela veut dire que
dans ce cas présent, cette fonction n'appellera ... qu'une seule autre
fonction !
<form name = "FrmGlossairetrie"> |
Le nom du formulaire vient de la table/requête. Si c'est une
requête, le préfixe "Rjs" est retiré |
<h2> Choisissez Terme</h2> |
Documentation |
<SELECT NAME="Terme" onchange="return ToutEcrireFrmGlossairetrie()"> |
Le nom du champ (ici "Terme") vient de la première colonne de
la table / requête |
<SCRIPT LANGUAGE="JavaScript"> EcrireOptionsTerme()
</SCRIPT> |
La fonction pour la liste déroulante |
</SELECT><BR> |
Fin de la liste |
<h3>Definition</h3> |
Documentation |
Fonction ToutEcrireFrmGlossairetrie()
appelant elle-même la fonction EcrireDefinition()
<br> |
Documentation |
<TEXTAREA NAME="Definition" COLS=80 ROWS=3> |
Début de(s) zone(s) de texte, avec pour nom le(s) autre(s)
champ(s) |
</TEXTAREA> |
Fin de la zone de texte |
</FORM> |
Fin du formulaire |
Le résultat est juste ci-dessous !
Bien qu'il s'agisse d'un "copier/coller", les niveaux de titre
(<Hn>) ont été adaptés en n+1.
SAV (Service Après Vente)
Y en a pas, puisqu'il n'y a pas de vente !
Bye, Pascal
Accueil cardware