Discussion :

[OtObOx]

Bonjour,

Lors d'une base organisée en client (formulaires et requêtes) -> serveur (tables des données), il faut mettre la partie client en local sur son ordinateur.

Je cherche une méthode pour distribuer l'appli aux différents utilisateurs car je n'ai pas envie de passer sur chaque poste pour faire un copier-collé de la base sur le bureau de certains de mes collègues qui n'y connaissent pas grand chose dans les manipulations de fichiers...

Pour l'instant, je pense que je vais procéder comme suit:
- sur le serveur, je vais laisser une copie de l'application.
- lors de son premier lancement par un utilisateur, test sous vba pour savoir l'emplacement du fichier lancé.
- si le fichier est sur un disque réseau (<> "C:"), alors copie (filecopy source, cible) sur le bureau de l'utilsateur. Le fichier source étant à un autre emplacement que celui lancé car sinon, la fonction, filecopy plante...
- message d'avertissement pour dire que le fichier est sur le bureau de l'utilisateur et indication que la prochaine fois, il faudra passer par là.
- chargement du fichier de l'appli copié sur le bureau
- fermeture de l'appli lancée sur le disque réseau.

Le défaut de cette méthode, est que je dois laisser l'appli à 2 endroits différents: à l'accès habituel et à l'emplacement "sources".
Je pourrais aussi distribuer l'appli par mail, mais je suis certain que quelques uns de mes collègues ne savent pas détacher une pièce jointe et j'entends déjà mon téléphone sonner : "qu'est ce que je fais du fichier que tu m'as envoyé ?"

Je cherche aussi une méthode pour remplacer automatiquement les appli distribuées par une version plus récente.

Et vous, comment faites vous ?

Jean-Marc

[bernardmichel]

Hello !

Pour ton info, Access n'est PAS client-serveur

La nomenclature est Frontale ("client") & Dorsale ("serveur"). C'est pas grave en soi, mais cela éclairci notoirement nos propos si nous parlons la même langue

Maintenant, pour passer aux choses plus sérieuses, je m'organise de cette façon (c'est la plus simple et la plus pratique que j'ai expérimenté...)

1. Je transforme ma MDE en un fichier Winrar en utilisant l'option SFX qui transforme le fichier en un exécutable
2. Dans cet exécutable, je peux choisir (forcer) le répertoire de décompression
3. Je place - comme tu le suggères - ce fichier sur le serveur et chaque utilisateur va y faire un double-clic
4. Tu peux également leur envoyer un mail avec un lien hyper-text qui pointe sur ce fichier

Le problème est la liaison des tables si le serveur n'est pas répertorié avec la même lettre sur chaque poste, je te laisse le soin d'aller voir la FAQ à ce propos, c'est relativement simple...

[OtObOx]

D'accord, je retiens que Access n'est pas client - serveur As tu un lien (ou 5 minutes) pour m'expliquer la différence ?

Ta méthode de distribution résout mon premier problème, celui de faire exécuter la frontale sur le poste en local, mais si l'application évolue, rien n'empêche l'utilisateur de se servir de sa version obsolète installée sur son C: si le lien donné par le mail n'est pas cliqué.

J'en suis à regarder la création d'un fichier ini pour définir la version courante de ma base.

Jean-Marc

[bernardmichel]

J'en suis à regarder la création d'un fichier ini pour définir la version courante de ma base.

C'est effectivemnet la solution que j'ai adpté !
Et à ce moment-là, tu as conçu un nouveau EXE sur le serveur

[bernardmichel]

Pour ta question Client/Serveur :

Définition :Client/Serveur , un exemple :
Dans votre base de données, vous avez 10000 clients, et vous souhaitez afficher la liste des clients de Grenoble, qui sont au nombre de 50. Dans un système "client/serveur", c'est le serveur qui va extraire les 50 clients et les transmettre à l'ordinateur concerné via le réseau. Seuls 50 clients transitent ainsi par le réseau.
Par opposition, dans un système "serveur de fichiers", c'est l'ordinateur de l'utilisateur qui fait le travail. Dans un tel système, même si vous ne souhaitez que les 50 clients de Grenoble, ce sont 10000 clients qui circulent sur le réseau, et seulement en final votre machine qui filtre les 50 personnes concernées.
Access et son moteur Jet fonctionnent en "serveur de fichiers", ce qui explique que les performances se dégradent avec un nombre d'utilisateurs important ou sur de grandes distances.
N.B. Par contre, Access et son moteur alternatif MSDE fonctionnent en client/serveur, ainsi que SQL Server et autres Oracle...

Et quelques lectures...
http://sqlpro.developpez.com/cours/sgbdr/
http://fr.wikipedia.org/wiki/Client-serveur


Bernard.

[OtObOx]

OK, super clair ! Merci pour ces explications

Bon dimanche,

Jean-Marc

[bernardmichel]

Merci, pareil à toi ! Moi, je vais profiter du soleil de Provence

[OtObOx]

Je reviens à la charge avec ma diffusion de la base automatique.

J'ai codé un truc en vba qui fait ce que je décrivais dans mon premier message

- sur le serveur, je vais laisser une copie de l'application.
- lors de son premier lancement par un utilisateur, test sous vba pour savoir l'emplacement du fichier lancé.
- si le fichier est sur un disque réseau (<> "C:"), alors copie (filecopy source, cible) sur le bureau de l'utilsateur. Le fichier source étant à un autre emplacement que celui lancé car sinon, la fonction, filecopy plante...
- message d'avertissement pour dire que le fichier est sur le bureau de l'utilisateur et indication que la prochaine fois, il faudra passer par là.
- chargement du fichier de l'appli copié sur le bureau
- fermeture de l'appli lancée sur le disque réseau (ou sur le bureau si c'est une version obsolète).

Ca marche très bien, sous NT et winXP. Aucun bug, je suis content et je vois ma base frontale installée sur les différents postes au fur et à mesure des connexions par les différents utilisateurs.
Seulement voilà, il y a quand même un truc... Si la dorsale ancienne version est déjà copiée sur le bureau, l'utilisateur peut relancer cette version obsolète puisque je ne l'efface pas (je ne peux pas la supprimer puisque le fichier est ouvert !) Alors, j'ai eu droit cet après-midi à "Je ne comprends pas ! Maintenant, à chaque fois que je lance ta base, j'ai toujours des messages qui me disent que la base est copiée sur mon bureau. Y'a un bug ou quoi ?"

Bon... mon collègue n'a pas lu les 4 messages d'avertissement qui disent que:
- y'a une nouvelle base
- qu'elle est copié sur le bureau
- qu'il faut utiliser dorénavant la version X.X
- qu'il faut effacer la version X.X-1

C'est décourageant !

Personne connait un truc en vba pour effacer un fichier ouvert ? Ca éviterait ce problème... (en même temps, le nouveau problème serait : "mais où donc est passée ta base de donnée ?" - j'ai déjà eu droit, après que j'ai eu déplacé un icone qui était en haut à gauche sur le bureau pour le placer en bas à droite à un : "mais où as tu mis AutoCAD ? tu l'as supprimé ?" - "Nan ! j'ai déplacé l'icone, tu vois en bas ?" - "Ha oui ! mais si tu commences à tout déconfigurer, comment tu veux que je m'y retrouve ?!!!?")

Jean-Marc

[Domi2]

Bonsoir,

Jamais testé, mais je m'intéresse aussi à la chose...

Soit un raccourci sur le bureau pointant sur un fichier VBS.

Le dit fichier contrôle que l'appli en local est de version égale à celle placée sur le serveur.

Si oui, lancement de l'application...

Si non, copie de l'appli serveur en local (écrasement de la version locale) et lancement de l'application...

Domi2

P.-S. Il faudra vraiment que je me mette sur le sujet...

[bernardmichel]

Hello !

Message de Domi2 et....

.. placer ta base non pas sur le bureau mais dans un répertoire dédié. Ainsi, l'utilisateur voit et clique toujours sur la même icône du raccourcis mentionné ci-dessus.

[OtObOx]

Oui, astucieux ! Je ne connais pas trop les VB scripts, ça va me donner l'occasion de m'y mettre.

Merci,

Jean-Marc

[marot_r]

Voilà comment nous avons résolu le pb dans mon entreprise.

Nous créons un fichier d'installation avec Setup Generator qui nous produit un .exe. N'importe quel outil de déploiment qui fait un exe est bon.

Ensuite nous plaçons ce .exe sur une de nos serveur FTP.

Dans la base de données, sur le serveur de données, nous avons une table Version qui contient pour chaque version :

• un numéro de version,

• une date de début,

• une date de fin

• et le chemin d'accès à l'exécutable d'installation (ex : http://Serveur1/MAJ/MonApli/instMonAppli200.exe).

Cette base est accessible au développeur.

Dans le code de l'appli il y a une constante NUM_VERSION qui est définie (ex : const NUM_VERSION as String = "1.00")

Quand l'appli démarre elle commence par tester le numéro de version en fonction de la table des versions pour savoir si la version est toujours active (Date de fin = 31/12/9999).

Si la version n'est plus active (date du jour n'est pas entre Version![DateDebut] et Version![DateFin]) alors le code suivant s'execute aprés avoir initialiser cehminAInstaller :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
    If Not versionOK Then
        ' si la version n'est pas à jour on ferme l'application
        ' et on appelle un installer automatique
        'Et on ferme l'appli courrante.
 
        Dim mess As String
        mess = "Votre application n'est pas à jour."
        mess = mess & vbNewLine & vbNewLine
        mess = mess & "L'application va se fermer et le système va installer la nouvelle version"
        MsgBox mess, vbInformation, "Mise à jour automatique."
 
        Dim WshShell
        Set WshShell = CreateObject("Wscript.Shell")
        WshShell.Run cheminAInstaller
        Set WshShell = Nothing
 
        db.Close
 
        Application.Quit
    End If

La date de début permet de connaître la version active la plus récente et la date de fin permet d'avoir plusieurs versions actives en même temps.

Ce système fonctionne super bien.

A+

[bernardmichel]

Bonjour

Merci pour toutes ces infos. J'aurais été intéressé par la composition de ton EXE mais le lien que tu as donné n'est pas valable. Aurais-tu la gentillesse de nous le modifier ?

Merci d'avance !
Cordialement
Bernard.