Mise à jour d'une application online et gestion des versions

Bonjour à tous

Quelle serait selon vous la meilleure approche pour que les mises à jour qu'un dévelopeur crée de son application soient applicables à plusieurs bases à la fois ?

Je veux dire dans le cas où le client crée plusieurs copies d'une même base vierge (car il utilise la même appli sur différents projets et chacune d'elle contient un data différent ...)

Pour l'instant le client m'envoie chaque base et c'est à moi de faire les updates manuellement...

Je pense créer une petite appli qui recherchera toutes les bases sur un pc/réseau et les mettra à jour en se basant sur un fichier que j'aurai distribué, mais comment solutionner les points suivants ? :

1/ Pouvoir reconnaître et vérifier qu'il s'agît bien de la bonne appli et que la mise à jour lui est applicable (uniquement avec le nom de l'appli renseigné dans Access ?)

2/ Offrir la possibilité de faire un update sélectif des objets d'une base si et seulement si les objets ont changé de version ou ont été modifiés (pour accélérer les temps de traitement...)

3/ Peut on "marquer" une version (en vba) de chaque objet (dans sa description ? ou date de modification ?) de façon à faciliter la détection de version de celui-ci ?

4/ Enfin, peut on déployer une mise à jour sur internet ou réseau sans que des problèmes de permissions apparaissent ?

5/ Vaut il mieux faire les maj en local grâce à un fichier spécialisé ?

Je n'ai aucune difficulté à coder ce genre de chose en vba (traitement par lot etc...) mais j'ai des lacunes en ce qui concerne la gestion de versions avec Access, à part le champ description d'un objet je ne vois pas si l'on peut ou non accéder à d'autres infos du dit objet...

Merci d'avance pour vos réponses / aiguillage

Bonjour,

1/ Pouvoir reconnaître et vérifier qu'il s'agît bien de la bonne appli et que la mise à jour lui est applicable (uniquement avec le nom de l'appli renseigné dans Access ?)

Une suggestion qui tient la route, consisterait à déclarer des constantes qui identifient le nom de l'application au sein de l'application elle-même et une procédure de vérification vérifie que le nom du fichier correspond bien à la constante.
Dans ce cas, l'application est à même de réagir vis-à-vis de la base de données dorsale à mettre à jour.
En ce qui concerne les versions, le plus simple est de créer une table versions dans la base dorsale avec une valeur de type single pour pouvoir faire des release avec une notion de version major, minor et build.
Lorsqu'une nouvelle version de l'application est déployée, elle possède une constante en dure de sa nouvelle version avec un incrément idoine.
Lorsque cette application est lancée, elles lit la table Version dans la base dorsale et compare : si une différence existe, elle applique un certains jeu de procédures à la hauteur de ce que vous voulez mettre à jour. Sur ce point, la procédure de mise à jour est relativement complexe mais tout à fait réalisable.

2/ Offrir la possibilité de faire un update sélectif des objets d'une base si et seulement si les objets ont changé de version ou ont été modifiés (pour accélérer les temps de traitement...)

Là, pour moi c'est sans objet.. Il n'y aura pas de problème de performance de mise à jour d'objets car il faut savoir qu'un formulaire est ni plus ni moins qu'un fichier texte et sa volumétrie est ridiculement petite par rapport à l'esprit qu'on pourrait en avoir.
Vous pouvez oublier ce point.

3/ Peut on "marquer" une version (en vba) de chaque objet (dans sa description ? ou date de modification ?) de façon à faciliter la détection de version de celui-ci ?

Vous pouvez, mais encore une fois ce sera au niveau de la page du module de l'objet en question (un formulaire par exemple) ne serait-ce que pour vous au niveau du débogage de savoir si vous bénéficiez bien de la dernière modification du formulaire mais comme vous êtes censés déployer l'application complète qui possède tous les nouveaux objets, il est inutile de vous pencher sur ce cas de figure un peu comme vu au point numéro 2.

À partir du moment ou vous délivrez nouvelle version, c'est la numéro de version qui fait foi et qui vous dit que de toute façon, le client bénéficie des derniers objets mis à jour, qu'ils aient été modifiés ou pas.

4/ Enfin, peut on déployer une mise à jour sur internet ou réseau sans que des problèmes de permissions apparaissent ?

Là c'est un autre débat, car il vous faut développer un site Web spécifique et faire en sorte que votre application y vérifie des éléments sur ce site, donc dans une base de données Web avec des droits spécifiques. Donc il faudra que vos clients s'inscrivent à ce site avec tout les éléments constitutifs d'une inscription et se loguent lorsqu'il s'agit d'effectuer des opérations particulières notamment, les mises à jour.
Le processus alors téléchargerait la nouvelle version et un exécutable en parallèle serait lancé à la suite de cela pour mettre à jour votre application directement à partir de la source téléchargée.

5/ Vaut il mieux faire les maj en local grâce à un fichier spécialisé ?

Cette question est exposée avec une proposition au point numéro 1.

Argy

Merci beaucoup Argyronet pour votre réponse cependant :

Lorsque je mentionne la détection de versions:

C'est dans le but de réduire le temps de traitement uniquement aux objets qui ont été modifiés par rapport à la base qui servirait d'update, comment distinguer deux versions d'un même formulaire par exemple ?

Je sais comment coder tout le procesus d'import d'objets ou de data mais l'idéal serait de pouvoir faire en sorte que le code puisse comparer les versions non pas seulement de la base active mais des objets en eux-même évitant des importations inutiles et du temps de perdu...

J'ai plusieurs clients qui utilisent des centaines de fichiers contenant différents projets et data mais basés sur une même version d'appli, ladite appli étant améliorée au fil du temps.

Je suis entrain de mettre au point un utilitaire qui détecte toutes les bases existantes sur les différents Pc et qui devra donc proposer un update de toutes les bases satellites en traitement par lot... d'où l'importance de la détection des versions...

Bonjour,

Voir s'il ne serait pas possible d'utiliser la propriété "Description" de chaque objet d'une base de données. Un code listant les objets et leurs "descriptions": Get the name and description of all MS Access database objects.

Reste qu'à mon avis il est vraiment beaucoup plus simple de remplacer directement l'entièreté de chaque application mise à jour (à un moment de la journée où l'application n'est pas ouverte) si chaque pc lance l'application au départ d'un raccourci.

Cordialement.

Humm, ne confondez pas MS Access et DotNet ou Java ou tout autre IDE de DEV pointu.

Il est pour ma part absolument délicat et risqué de mettre à jour juste un élément de l'application juste parce qu'un contrôle a changé dans un formulaire d'autant plus que si vous voulez protéger votre application et qu'elle est encryptée en ACCDE, ce qui est fortement recommandé, vous ne pourrez pas mettre à jour votre application.

Si je me suis permis de vous suggérer l'alternative telle que je n'ai exposée, c'est parce que lorsqu'il y a une nouvelle version de l'application il n'y en a qu'une et ce n'est pas parce que vous avez changé une instruction SQL, colorié un bouton ou ajouté une liste déroulante dans un écran qu'il ne faut affecter que cet objet. Il y a des impondérables comme des blocs de code inhérents à ce formulaire et des fonctions externes modifiées, même si vous aviez modifié les paramètres en Optional.
Comment d'ailleurs allez vous recoder/mettre à jour une ou plusieurs fonctions/procédures au sein d'un module privé ?
Je serais curieux de savoir...

Ce sera très coûteux en développement pour pas gagner grand-chose si ce n'est peut-être quelques millisecondes. Et encore. Mesurer un FileCopy à votre MAJ "maison", je reste sur mes gardes.

Mais effectivement si vous voulez rester sur votre idée, je n'y vois pas d'inconvénient.
J'ai plus de 25 ans d'utilisation Microsoft Access et de MS Office en général (côté développeur), et jamais une idée aussi saugrenue n'avait effleuré l'esprit...
Je ne dis pas qu'elle est stupide, je dis que l'application n'est pas faite pour envisager une telle perspective de développement.

Lorsque vous faites du DEV avec de vrais outils comme Visual Studio ou encore Intel IJ et que vous modifiez un élément, vous avez la possibilité de faire ce que l'on appelle un patch puisque tous les éléments sont décorélés de l'application principale et notamment les bibliothèques, fichiers de paramètres, fichiers SQL etc...

Si votre application Microsoft Access utilise des DLL/OCX à foison autour de l'application, alors effectivement oui vous pouvez déployer uniquement la nouvelle version de la DLL/OCX mais il faudra prévoir dans votre module d'installation la possibilité de l'inscrire en tant que composant COM ainsi que cela doit l'être si vous voulez que votre application continue de fonctionner en « mode de compatibilité binaire »...

Argy