Discussion :

[windiver]

Bonjour,

J'ai développé une petite application en Runtime Access 2007. Les utilisateurs téléchargent, installent et utilisent la base sur leurs PC perso (hors réseau).
J'ai développé un système de mise à jour des données en téléchargement des fichiers .txt sur un serveur web/ftp... ça marche nickel (mise à jour et récupération de données).

Mon problème... j'ai des mises à jour de la structure de la base & du code VBA et je ne sais pas comment faire (à part dire aux utilisateurs de désinstaller et ré-installer le nouveau fichier .msi). J'aimerais que ce soit plus transparent.

Est ce qu'il y aurait une astuce pour remplacer la base de données de tous les utilisateurs ?
Je pensais peut être générer un fichier .bat qui remplacerait la base de données au prochain démarrage de Windows par exemple... Est ce possible ?
Je suis preneur de tout conseil/suggestion

Par avance, Merci
Laurent

[argyronet]

Bonjour,

Il y a plusieurs solutions...
Une idée parmi tant d'autres consiste à stocker le version en vigueur et la version de l'utilsateur sur un FTP pour le premier et dans une table pour le second, les comparer et agir en conséquence par lancement du téléchargement de la nouvelle version.
Tout ce déroulement peut se faire par un EXE externe ou par l'application elle-même, la difficulté restant sur l'enchainement du cycle qui soit se limite à la copie de la dernière version soit à sa réinstallation.
En effet, en cas de modifications majeures (références notamment), tu es contraint de désinstaller puis réinstaller ; sinon, un simple remplacement du fichier de BDD suffit.
Donc le coté "transparent" de la chose me parait difficile à mettre en oeuvre.

Sinon, tu peux jouer tout cela dans un MSI si tu sais les éditer et les manipuler de façon conditionnelle. (voir ce post)

Argy

[windiver]

Bonjour Argi,

Tout d'abord, merci pour ta réponse !

Je viens de finaliser la partie test de version. J'ai isolé les 2 cas :
- Les modifications majeurs (avec nécessité de désinstallation / ré-installation) : Passage d'une version v2 à v3 (par exemple) - Pour l'instant, j'ai juste un message à l'utilisateur.... (je laisse ça pour plus tard)
- Les modifications mineurs (avec copie/écrasement de la BD) : Passage de la version v2.4 à v2.5 (par exemple) - Et là, je sèche un peu...

Comment puis-je faire pour que depuis ma BD active... l'écraser par la mise à jour ? Que recommandes-tu ?

(Est ce qu'il y a moyen de faire un téléchargement - ftp ou html - en arrière plan pour ne pas bloquer l'utilisateur pendant le téléchargement de la mise à jour? )

Merci d'avance
Laurent

[titi95]

Bonjour

A titre d'exemple, une solution que j'ai appliquée après en avoir étudié plusieurs autres.

Pour une base :
- à disposition d'utilisateurs particuliers, indépendants,
- dans laquelle est fournie une table de données qui fait l'objet de mises à jour régulières,
- table complétée sur des champs ouverts aux utilisateurs

Solution retenue :
- une petite base qui ne nécessite aucune mise à jour et qui ne sert qu'à ouvrir la base de données
- la base de données qui est numérotée suivant le numéro de version, contient les mises à jour de la table ET les modifications de la base (nouvelles fonctionnalités...)
- l'utilisateur met la nouvelle version vierge dans le même dossier que la précédente et clique sur le raccourci
- la base d'ouverture reconnait la nouvelle version et récupère les données propres à l'utilisateur dans la précédente pour les rajouter dans la nouvelle.
C'est rapide et facile pour l'utilisateur.

Avantage : cela évite de faire une mise à jour classique qui, dans mon cas, devenait impossible à gérer ; on fournit simplement une nouvelle version complète vierge qui se met automatiquement à jour (30 s) des données utilisateurs.

Si cela peut te donner des idées...

titi95

[argyronet]

Il ne faut pas penser sans cesse arrêt de productivité si mise à jour il y a...
Tu lis la version en cours et s'il existe une nouvelle version alors un message s'affiche à chaque fois que l'utilisateur clique sur des boutons à fonctions disons stratégiques...

2 type de messages possibles :

1. Le message l'informe alors que des nouvelles fonctionnalités existent et ne l'empêche pas de travailler
2. Le message l'informe alors que des nouvelles fonctionnalités existent et bloque l'accès à tel ou tel formulaire et l'oblige à faire sa MAJ.

De là, il faut lancer un process parallèle en asynchrone qui télécharge la version via le procédé que tu veux mais fenêtré (pas en silence car l'utilisateur apprécie de savoir ce qui se passe) et donc un programme dédié (pourquoi pas une autre application Access développée pour la circonstance) que tu mets au premier plan avec un SetWindowPos() puis l'application visée de ferme, laissant ainsi l'exclusivité au programme de MAJ.

Quand ce dernier à terminé le téléchargement, il remplace la version ancienne puis lance l'application nouvelle version...

Argy

[windiver]

Bonjour,

Merci à vous deux titi95 et Argy !
Grâce à vous, je commence à entrevoir des solutions

titi95 : Intéressant d'avoir une base de données frontale (presque vide) qui fait le contrôle de version, qui éventuellement télécharge la dernière version dispo sur un site ftp/html et puis qui lance la version dispo sur le poste de travail...
Il faut que je fasse des tests !

Argy : Oui, effectivement je voyais bien les messages non bloquants, juste informatif. Libre à l’utilisateur d'accepter de faire les dernières mise à jour pour bénéficier des dernières fonctionnalités !
Si je comprends bien, dans ta solution, c'est le contraire de titi95. La base principal (avec table, formulaire et code VBA) est lancé en premier, et si besoin lance un processus en parallèle pour faire le téléchargement puis copie (après fermeture de la base principal)...
C'est plus proche de ce que j'ai maintenant...

Les 2 versions me semblent pertinente, je ne vois pas encore quelle est la meilleure formule... à tester !

Encore merci et bonne journée
Laurent