Discussion :

[denisduval75]

Bonjour,

Je souhaite déployer mon (laborieux) travail sur des postes clients.
Par chance chaque poste doit disposer de sa propre base (pas de partage ou base commune).
Pour assurer la maintenance de mes formulaires, je souhaite évidemment séparer la base des formulaires ...

J'ai vu qu'Access permet cela, mais :

- Comment gérer le chemin d'acces au fichier base sur les postes clients ?

- Ensuite après déploiement, comment faire évoluer la base (par exemple ajouter une colonne à une table) ?

- Enfin, comment générer un exécutable puisque Access ne sera pas forcément installé sur les postes clients ?

MERCI infiniment

[Invité]

Bonjour
Un peu de lecture ici pour donner des pistes.

[marot_r]

Bonjour

En complément de la réponse de GAYOYT :Salut:

Par chance chaque poste doit disposer de sa propre base (pas de partage ou base commune).

Quand tu dis qu'il n'y a pas de base commune, veux-tu dire que ton application et ses données résident sur le poste client ?
Que tu n'as pas l'architecture classique : la frontale (formulaires, états, requêtes, code ...) sur le poste client et les données sur un serveur partagé ?

Pour le moment je vais supposer que tu as Frontale locale et Dorsale réseau.

- Comment gérer le chemin d'acces au fichier base sur les postes clients ?

Grâce au gestionnaire de tables liées, tu peux préciser où se trouve la BD.
La solution la plus simple est de s'assurer que ta BD dorsale soit "à la même place" pour tous les clients (ex : \\TonServeur\TonRepertoire\).
Sinon tu peux, par VBA, assigner un chemin via la propriété .Connect de l'objet TableDef et la méthode .RefreshLinkCe que je fais quand je dois le faire c'est que je teste à l'ouverture si ma DB Dorsale est visible avce Dir(). Si je la trouve c'est OK, sinon j'ouvre un formulaire de saisie où je demande le nouveau chemin. J'applique ensuite ce chemin à tous mes objets dao.tabledef de l'objet dao.database et la collection .TableDefs.

- Ensuite après déploiement, comment faire évoluer la base (par exemple ajouter une colonne à une table) ?

Pour la dorsale, tu fais les modifs dans la dorsale et tu fais un rafraichissement des liens. Les modifs seront prises en compte.
Pour la frontale, tout dépend de la taille de ta frontale.
Si elle est relativement petite, la solution la plus simple est de recopier à chaque démarrage un modèle que tu déposes dans le répertoire commun avec un .bat du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
copy \\TonServeur\TonRepertoire\TonModele.accdb C:\TonRepertoire\*.*
call "C:\TonRepertoire\TonApplication.accdb"

L'avantage c'est que tu es sûr que ton client a toujours la dernière version.

Si elle est trop grosse, alors il faut tester puis copier.

Dans ce cas là on peut mettre un table VersionReseau dans le modèle qui est liée au modèle sur le réseau et qui est comparé au contenu de la table VersionLocale.
Si VersionLocale<VersionReseau alors tu alertes l'utilisateur, tu appelles un .bat avec un message du type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
echo Appuyer sur la touche [Entrée] losrque la base de données est fermée.
pause
copy \\TonServeur\TonRepertoire\TonModele.accdb C:\TonRepertoire\*.*
call "C:\TonRepertoire\TonApplication.accdb"

Tu fais un docmd.quit pour fermer l'application.

Quand l'utulisateur a confrimé que la BD est fermée par appuis sur [Entrée], la nouvelle BD est copiée ne local puis ouverte.

A+

[denisduval75]

Bonjour et merci beaucoup à toi Marot_r de prendre le temps de me répondre.

J'ai bien lu ton message, mais je suis complètement perdu

Oui l'application et les données doivent résider sur le poste client. Chaque client doit disposer de sa propre base. Donc pas de serveur à gérer : ni pour l'application, ni pour les données. Chaque poste client doit être absolument autonome.

Je veux juste, sur le PC de l'utilisateur, un fichier pour l'application et un autre pour les données. C'est tout !
Chaque client (ou PC) a à gérer des infos qui lui sont propres, et elles ne doivent jamais être partagées !

Chaque client doit donc disposer de sa propre base sur son PC, accessible par lui et lui uniquement et personne d'autre.

En principe il s'agit du cas le plus basic qui soit, non ?

Marot_r, si tu pouvais à nouveau prendre quelques minutes pour me répondre, je t'en serais infiniment reconnaissant car mes clients commencent à s'impatienter et moi je commence à stresser grave ! MERCI ...

[marot_r]

Bonjour.

En principe il s'agit du cas le plus basic qui soit, non ?

En fait, non.

Pour la distribution sur chaque poste pas de problème majeur. Tu zippe le tout et tu l'envois par Courriel avec les instructions d'installation ou tu utilises un "packageur".
L'article mentionné précédemment répond au problème du packageur il me semble.

Tes problèmes vont survenir pour les mises à jour.

Si tu changes seulement la frontale, là aussi pas de problème, c'est comme une installation initiale qui vient écraser la version existante.

Pour la dorsale c'est BEAUCOUP plus compliqué car il faut par un moyen ou un autre refaire toutes les modifications que tu as faites en développement dans ta dorsale de production.

Une solution serait que tu distribues un "Metteur à jour". C'est à dire une BD Access qui ouvre ta dorsale et la modifie (via VBA ou SQL). Je n'ai jamais fait de chose semblable mais je sais que c'est possible.

On peut même, sans-doute, intégrer le module de modification dans la dorsale et via un fichier de paramètres ou autre faire en sorte qu'elle se modifie elle-même.
Avec un fichier de paramètres, utiliser du SQL sera probablement le plus facile. Le fichier contiendrai des truc du genre "ALTER Table ...".

Ce n'est pas simple et c'est pour cela que dans la mesure du possible on place la dorsale sur le réseau accessible au développeur.
Il faut certes refaire les modifs mais c'est à une seule place et on ne dépend pas d'un automate.

Avec une recherche Google "Microsof Access update back-end" voici ce que j'ai trouvé

http://www.peterssoftware.com/beu.htm

Ça parait intéressant mais je n'ai pas regarder le code.

A+

[Invité]

Je veux juste, sur le PC de l'utilisateur, un fichier pour l'application et un autre pour les données. C'est tout !

Bonjour denisduval75, Bonjour marot_r

Tu veux donc une appli frontale\dorsale.

Encore un peu de lecture ici
Même si ce n'est pas en multi-utilisateurs, le principe est le même.

[argyronet]

Bonjour,

J'apporte mon grain de sel même s'il fait doublon...
En fait, ta base Frontale (Appli) doit posséder :

• une procédure de rattache automatique des tables
• une procédure qui procède aux différentes modifications de structure et de données dans la base frontale (INSERT, DELETE, UPDATE, ALTER)
• une pocédure qui verifie la version (inscrite en dur dans ton code : Version_Actuelle)

Ca donne (grossièrement):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
If Version_Actuelle < Version_Livree Then
    LancerMajStructureDonnee(Version_Actuelle)
End If

où LancerMajStructureDonnee(Version_Actuelle) est la procédure qui procède aux éventuelles modifications de la base dorsale et où le paramètre Version_Actuelle représente le numéro de la fonction ou du Case d'un Select Case pour ne pas procéder deux fois de suite (Erreur fatale) à une même modification déjà effectuée auparavant...

Bon, je sais, l'approche comme ça n'est pas simple mais c'est un moyen pratique pour distribuer des applis à différents clients répartis un peu partout dans le pays... quelque soit la version de leur appli...

Argy

[denisduval75]

Merci à tous pour vos réponses. Je vais étudier calmement tout ceci ... MERCI