Discussion :

[sabotage]

Bonjour,

Ayant bien appris ma leçon j'ai scindé ma base avec tables d'un côté et formulaire de l'autre.
Malheureusement je vais encore modifier ma partie appli assez régulierement.

Je voulais votre experience sur les moyens pour empecher un utilisateur d'utiliser une ancienne version de l'appli.

Je pensais faire la chose suivante :
- mettre un numéro de version dans ma base donnée
- inclure un bout de code dans l'appli avec le numero de version et le comparer à celui de la base

Qu'en pensez vous ?

Microsoft a t'il mis a disposition des moyens pour qu'un utilisateur recupere automatiquement la bonne version d'un MDE ou faut-il aller le remplacer sur son poste à la mimine ?

Merci

[keita]

sabotage a ecrit:

Microsoft a t'il mis a disposition des moyens pour qu'un utilisateur recupere automatiquement la bonne version d'un MDE...

Je ne comprends pas.comment l'utilisateur va t il recuperer ton appli MDE?
Non je crois qu'il faut aller lui mettre la bonne version ou bien le laisser fonctionner avec l'ancienne si tout fonctionne bien chez lui.

[Nohant]

Salut,

Personnellement j'utilise la méthode suivante : j'installe sur le poste utilisateur deux bases

l'utilisateur lance la base A qui sert uniquement à contrôler la version par rapport à la dernière version disponible. Si c'est Ok cela lance automatiquement la base B. Si c'est KO, recopie auto en local de la dernière version du client et lancement automatique.

Prévoir également de bloquer le lancement du client si la base centrale est indisponible (ex maintenance).

@+

[keita]

salut
soyons un peu concret; utilisons des images; peut etre que je comprendrai mieux:
Supposons donc que j'ai la version de ton appli developpée avc access 97
(version moteur jet 3.5 je crois)
je voudrais ta nouvelle version, avec access 2003 (ms jet 4.0), sachant que 'ai toujours access97 sur mon poste; alors tu fais comment concretement?

[sabotage]

Pardon je n'ai peut etre pas été assez clair, je parlais de version de l'appli pas de la version Access.

Je ne comprends pas.comment l'utilisateur va t il recuperer ton appli MDE ?

On aurait pu imaginer que le fichier MDE se mette à jour tout seul à partir d'un fichier reference.
Mais bon ...

[keita]

sabotage a ecrit:

Pardon je n'ai peut etre pas été assez clair, je parlais de version de l'appli pas de la version Access.

Euh à ma connaissance, la version de ton mde, c'est la versiond'access que tu as. En fait quand on parle de version en access, nous parlons de la version du moteur jet sur lequel repose access.
En un mot, il n'y a pas ta version à part et la version d'access à part!
peut etre que jez passe encore a coté du sujet.

[pht33]

Ben si, il y a une version Access qui évolue généralement peu, et une Version de ton application qui change souvent, surtout en phase de démarrage.
En ce qui me concerne, j'utilise généralement deux bases de données :
La première est partagée sur le réseau et contient les données + le dernier numéro de version de l'application.
La seconde est locale, contient l'application, des tables liées sur la base partagée, qulques données locales de paramétrage et aussi le dernier numéro de version de l'appli (pas d'Access).
L'appli est installée par un Setup (Inno Setup)

Lorsque je démarre l'appli, je teste si le numéro local de version est inférieur ou supérieur au numéro distant.

S'il est inférieur, j'indique à l'utilisateur qu'il n'a pas une version à jour.

S'il est supérieur, je met à jour le numéro de version distant avec le numéro de version local (ce qui indique que le poste à fait une mise à jour de son appli)

Je ne gère pas la mise à jour automatique de l'appli, il me manque encore quelques infos techniques.

[Nohant]

sabotage a ecrit:

Pardon je n'ai peut etre pas été assez clair, je parlais de version de l'appli pas de la version Access.

Euh à ma connaissance, la version de ton mde, c'est la versiond'access que tu as. En fait quand on parle de version en access, nous parlons de la version du moteur jet sur lequel repose access.
En un mot, il n'y a pas ta version à part et la version d'access à part!
peut etre que jez passe encore a coté du sujet.

je pense que la phrase est "pour qu'un utilisateur recupere automatiquement la bonne version de l'appli au format MDE"

un mde est compatible avec les versions postérieures.

Le plus simple est carrément de remplacer l'appli locale par la dernière version disponible sur le réseau. Perso je le fais en utilisant la librairie scripting runtime ==> simple copie d'un fichier comme n'importe quel fichier.

C'est l'intérêt de ma conception à trois bases (deux sur le poste de l'utilisateur et la base centrale) car il n'est évidemment pas possible d'écraser l'appli si elle est lancée.

Cdt

[zoom61]

Salut,

Ce que tu peux faire c'est mettre le programme et la base sur le même serveur. Le programme pourrait être ouvert par plusieurs personne, et doit il te suffira de modifier le fichier sur ce serveur pour que la mise à jour des versions se fasse tout seul.

C'est comme cela que je fais, je développe des applications avec un fichier base et un fichier programme, et toutes personnes ont un lien vers le programme, et je fais des modifs dans mes programmes.

[pascalm]

Bonjour à tous

Je voudrais pas détourner le sujet mais j'ai un problème un peu similaire.

En fait je développe une appli (code + tables séparées) que vais donner à x personnes sur x machines qui ne sont pas en raiseau local. En gros chaque fois que je vais faire une modif de code je vais redonner le fichier mdb or comment ce fait la liaison avec l'autre fichier tables ? (autrement que par une opération manuelle gestionnaire de tables liées (je veux du code ex : DoCmd.RunCommand acCmdLinkedTableManager))

Merci par avance.

[zoom61]

Salut pascalm,

Ce que tu peux faire c'est mettre ton fichier des bases en mdb, et mettre au même endroit ton fichier programme (contenant : requêtes, formulaires, états, modules, etc...) au même endroit mais en mde, et quand tu feras des modifs, tu n'auras cas changer ton programme mde, ainsi aucun problème de diffusion de la nouvelle version (avec le risque d'oublier quelqu'un).

[Nohant]

Salut pascalm,

Ce que tu peux faire c'est mettre ton fichier des bases en mdb, et mettre au même endroit ton fichier programme (contenant : requêtes, formulaires, états, modules, etc...) au même endroit mais en mde, et quand tu feras des modifs, tu n'auras cas changer ton programme mde, ainsi aucun problème de diffusion de la nouvelle version (avec le risque d'oublier quelqu'un).

Salut,

cette méthode n'est pas très recommandée puisqu'elle revient à permettre à plusieurs utilisateurs d'utiliser simultanément la même appli avec les risques inhérents si celle-ci utilise des tables temporaires, des variables, ...

[Sunny]

Si je peux apporter mon grain de sel....

Pour ma part, j'ai monté le système suivant:

- sur le serveur j'ai une frontale + la dorsale data
- dans la dorsale j'ai mis une table paramètre avec le n° de version + une heure
- dans ma frontale, j'ai une table équivalente
- la frontale est copiée sur tout les postes utilisateurs
- à l'ouverture d'une frontale sur le poste client, il y a un test pour voir si le n° de version et/ou la date dans la dorsale est supérieur aux paramètres dans la frontale client... si c'est le cas on lance un utilitaire qui :

- ferme la frontale client
- lance un batch sur le serveur pour copier la nouvelle frontale vers le poste client

Et le client n'as plus qu'à relancer.

La manip consiste à ne pas oublier quand on mets une nouvelle version sur le serveur de mettre à jour les n° de version et date/heure dans les tables.


O

[wulfgar57]

QQn aurait un exemple concret
Avec les codes à lancer pour récuperer le numéro de version stockée dans une table
Et mettre à jour sa "version" en local en recopiant la nouvelle version existante sur le serveur, etc etc

merci d'avance