Discussion :

[naphta]

Bonjour,

Il y a un moment de cela je me suis penché sur la problématique de mise à jour automatique de frontaux. J’ai trouvé un certain nombre de chose avec google à ce propos.
L’impossibilité notoire est que le frontal ne peut être mis à jour s’il est lancé.

Il existe des logiciels relativement onéreux ou des solutions avec des tas de fichiers et une logique de fonctionnement très relative.
J’ai un peu de temps en ce moment, peut être la crise, alors je me suis penché de nouveau sur le problème.
Toutes les solutions proposées font une comparaison entre le frontal et la base centrale avec une information stockée dans une table avec un numéro de version.

J’ai refait un bilan des choses nécessaires :
L’information « nouvelle version » doit être comparée entre 2 frontaux
Ce qui importe n’est pas le numéro de version mais la date de celle-ci
La mise à jour doit-être automatisée en dehors du frontal

J’ai donc choisi la solution du script VBS, lancé au « logon ».
Il faut un point de distribution
Une table version avec 2 champs, un pour la version et l’autre pour la date et le script
On modifie le login script du serveur
Dans le script on positionne le point de distribution avec le nom du frontal et le point d’arrivée.

Ce script a été testé in situ et cela fonctionne sans souci dans un environnement Windows 2003.

Je propose à ceux qui le désirent de faire des propositions d’amélioration afin de solutionner cette problématique.

1 Dans le répertoire NETLOGON du serveur le fichier script de login ex : "LOGIN_SCRIPT.bat" on ajoute la ligne

Code :

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

1
2
 
\\monserveur\NETLOGON\MaJFrontal.vbs

le script vbs très simple

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
 
dim lasource 'Frontal en cours d'utilisation
dim FrtMaj 'Frontal supposé MàJ
dim ladateorigine 'Date Frontal en cours
dim ladateMaj 'Date Frontal supposé MàJ
 
'Emplacements physiques
FrtMaj = "G:\Distribution\Maj\LeFrontal.accdr" 'Frontal supposé MàJ
lasource = "C:\ExploitFrontal\LeFrontal.accdr" 'Frontal en cours d'utilisation
 
if FichierExiste(FrtMaj) = true and FichierExiste(lasource ) = true then
		ladateorigine = donneladate(lasource)
		ladateMaj = donneladate(FrtMaj)
 
		if ladateMaj > ladateorigine then
			copieFrontal
		end if
	else
	 	wscript.echo "Il y a un pépin avec les emplacements ou les noms de fichier"
end if
 
function donneladate(kelbase)
'Connexion à une base et interrogation
	Set conn = CreateObject("ADODB.Connection")
	strConnect = "Provider=Microsoft.Ace.OLEDB.12.0;Data Source=" & kelbase & ";Persist Security Info=False;" 
	conn.Open strConnect
	LeSQL = "SELECT Version.ladate FROM Version"
	Set rs = conn.Execute(LeSQL)
	rs.movefirst
	donneladate=rs(0)
	conn.close
	Set conn = Nothing
end function
 
Function copieFrontal
'Copie du Frontal
	Set fso = CreateObject("Scripting.FileSystemObject")
	fso.CopyFile FrtMaj , lasource
	Set fso = Nothing
 
end function
 
Function FichierExiste(leFichier) 
    Dim filesys
    Set filesys = CreateObject("Scripting.FileSystemObject")
    If filesys.FileExists(leFichier) Then
        FichierExiste = True
    End If
End Function

Voila that's all

[Papy Turbo]

Excellent sujet sur lequel je planche en ce moment.
Puis-je me permettre quelques questions de boulet concernant Windows et le système (dont je ne m'occupe que contraint et forcé, vu que "ça devrait marcher tout seul", donc ne suis ni à l'aise avec les NETLOGON..., ni fan de vbs...)

1 Dans le répertoire NETLOGON du serveur le fichier script de login ex : "LOGIN_SCRIPT.bat" on ajoute la ligne

Code :

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

1
2
 
\\monserveur\NETLOGON\MaJFrontal.vbs

Là, sorry, je ne comprends pas :
- si le fichier Login_script.bat, qui lance le script MaJFrontal.vbs, se trouvent tous 2 sur le serveur, dans le dossier (public ?) NETLOGON,
1- pourquoi un fichier *.bat, et pas directement lancer le script ?
mais surtout
2- qui lance l'exécution ? quand ?
3- pourquoi exécuter ce script sur le serveur, qui est public, mais qui devra copier vers le poste de travail, qui, lui, ne l'est généralement pas ?

Généralement, d'après ce que j'ai pu voir chez divers collègues, (dont l'ex-Vieux, Etienne Bar aïe, Etienne, arrête, j'ai rien dit, c'est pas moi, pour ne pas le nommer) la solution la plus simple consiste en :
- chaque utilisateur dispose d'un icône de lancement sur son bureau,
- l'icône de lancement de l'application (=frontal) lance en fait une autre mini-application dite "Lanceur",
- le lanceur exécute un code similaire à ton script (qui est remarquablement clair, bravo )
- après la copie (s'il y a lieu), le lanceur lance l'application proprement dite, et se ferme...

J'aimerais comprendre qui/quoi/comment se déclenche ton script ?

[Tofalu]

Je vais peut être dire une bétise. Mais pourquoi ne pas le limiter à un test sur la date des fichiers. Quoique, suffirait que les systèmes de fichiers ne soient pas synchro pour que ça foire. L'idée du numéro de version est pas mal. Je préferais cependant un objet DAO.Property par exemple. Le versionning étant typiquement une info liée à la base.

A priori, si le developpeur a mis à disposition un fichier sur le serveur, c'est d'une part qu'il souhaite la mise à jour et d'autre par qu'il est plus récent, non ?

D'autre part, se baser sur le simple nom de fichier me paraît un peu dangereux dans le sens où si l'utilisateur renomme le fichier, la MAJ ne se passera pas et l'utilisateur aura une version atérieure.

Enfin, ne se baser que sur un script externe c'est prendre le risque que l'utilisateur puisse controurner la MAJ (et donc contourner les nouvelles règles de gestions). Dès lors, il me parait nécessaire de :

- Confier l'écriture de la nouvelle base à un launcher comme le préconise PapyTurbo
- Ne pas oublier de faire le test au démarrage de l'application aussi.


On garantie ainsi que l'utilisateur ne bidouillera pas le VBS pour passer outre la MAJ.

[naphta]

Bonjour,

J’ai considéré un environnement avec un serveur Windows 200X où les utilisateurs ne font attention à rien et comprennent quasiment rien, le genre commercial et technicien de production.

Un script au login de l’utilisateur permet en général d’établir la connexion aux imprimantes réseau et unités logiques et faire divers tâches automatisées, il est « super » utile, il est lancé à chaque fois que l’utilisateur se connecte au serveur.
Le script de login se trouve dans un répertoire partagé du serveur et c’est toujours le même, c’est dans cet emplacement que je propose de copier le script VBS. Les scripts de login s’exécutent sur la machine client avec son environnement, il peut donc faire tous ce qu’un utilisateur peut faire.

Effectivement on peut avoir un fichier qui fait tout mais je préfère dissocier les choses pour les personnes qui passent derrière moi et qui vont se poser des questions sur le gonze qui à mis ses paluches dans leur script « standard ».

J’ai vu les solutions avec un lanceur format access compilé qui vérifie les mises à jour puis lance l’appli, cette solution est d’ailleurs aussi proposée par un MVP access américain, c’est celle qui m’a le plus emballée au début.
Dans l’alternative que je propose, le script est copié une fois sur le serveur et peut servir à n stations, pour n applis access sur la même machine, le test n’est pas effectué à chaque lancement du frontal, une solution pour flémards.

Je veux ajouter que l’on peut même lancer ce script à chaque démarrage d’une station XP ou vista en positionnant dans le registre l’appel au fichier, dans la section « Run ».

Encore merci à Papy Turbo d’avoir pris le temps de la critique.

[Papy Turbo]

J’ai considéré un environnement avec un serveur Windows 200X où les utilisateurs ne font attention à rien et comprennent quasiment rien, le genre commercial et technicien de production.

bien vu

Un script au login de l’utilisateur permet en général d’établir la connexion aux imprimantes réseau et unités logiques et faire divers tâches automatisées, il est « super » utile, il est lancé à chaque fois que l’utilisateur se connecte au serveur.
Le script de login se trouve dans un répertoire partagé du serveur et c’est toujours le même, c’est dans cet emplacement que je propose de copier le script VBS. Les scripts de login s’exécutent sur la machine client avec son environnement, il peut donc faire tous ce qu’un utilisateur peut faire.

Merci pour l'explic. Ça me plaît beaucoup.
Seul problème : en tant qu'indépendant, intervenant dans une grosse boîte (i.e. une boîte dotée d'un Service Informatique de plus d'1 personne), il faudra des mois pour obtenir l'autorisation de placer quoi que ce soit sur un serveur quelconque Entre temps, on en sera (au moins) à la version 3 de notre appli.
Donc, à conseiller pour un développement interne, et encore, seulement dans les boîtes ou le S.I. n'est pas sécuriphile au point de TOUT bloquer : je me contenterai de citer sans nommer une société de plusieurs diz. de milliers de postes, où il n'y a aucun lecteur USB pour empêcher toute contamination
En tout cas, pour les externes et autres prestataires, laisse béton...

le test n’est pas effectué à chaque lancement du frontal, une solution pour flémards.

flémard (abrégé de "fait le mariole" ?) = développeur VBA ?
J'en suis

Je vais peut être dire une bétise. Mais pourquoi ne pas le limiter à un test sur la date des fichiers.

Gagné !
Parce que,
- si tu installes une nouvelle application à 14h00 sur le serveur,
- si un utilisateur a son applicaiton ouverte à ce moment et la ferme à 14h01,
- la prochaine ouverture de la même appli ne chargera pas la nouvelle version (+ ancienne).

Quant aux considérations sur les divers bidouillages (du nom de fichier, du script...), je m'en tiens à la 1ère citation de naphta, en tête de ce post :
- 80% (ou +) des utilisateurs ne savent pas faire ça,
- les 20% restants, soit savent qu'il ne faut pas le faire, soit découvrent que c'est comme ça qu'on se fait virer

Donc, j'aime beaucoup cette solution totalement indépendante de notre appli, quand elle peut s'appliquer. Mais je crois que je continuer à flemmarder en VBA, pour les autres cas.

[Tofalu]

- 80% (ou +) des utilisateurs ne savent pas faire ça,
- les 20% restants, soit savent qu'il ne faut pas le faire, soit découvrent que c'est comme ça qu'on se fait virer

Mouais ce genre d'argument me laisse perplexe ...
Dans ce cas on abandonne aussi tout ce qui est sécurité... après tout chacun ses responsabilités ...

[curt]

Bonjour à tous,

voilà un sujet sur lequel j'étais en train de plancher. Avant de me lancer dans la réalisation, voilà une des idées, brut de pomme (Normandie oblige !!) :

J'ai une mise à jour dispo sur le serveur (NEW BDD)
J'ouvre une base (appelons-là BDD1) - Je compare le champs [Version] à celui de la base NEW BDD.
Si les champs sont identiques, j'ouvre ma base application (frontal)
Si les champs sont différents, c'est qu'il y a une mise à jour de disponible et je copie et remplace la base NEWBDD du serveur vers mon poste. Une fois la copie terminer, BDD1 lance ma base frontal alors à jour et je ferme la BDD1.

La copie de la base frontal est possible puisqu'elle n'est pas ouverte sur le poste et la mise à jour est transparente pour l'utilisateur (au pire, on affiche un message d'attente pour le faire patienter).
Par contre, ça oblige à avoir 2 bases d'installer dont une qui ne sert qu'à tester la version en cours de la seconde. (à mon avis, ça vaut le coup !)

J'aimerais avoir votre avis là-dessus.... moi je repart à mes pommes !!

Bonne soirée à vous.
Curt

[naphta]

Bonsoir,

Le répertoire Netlogon est toujours soumis à la même sécurité, lecture seule pour les utilisateurs et lecture écriture etc pour les administrateurs.

sinon l'idée soumise par Curt et dont Papy Turbo parle aussi, cette idée est bonne mais ici je file une alternative à celle-ci.

Dans un environnement où les responsables ne laissent pas les gens déposer des fichiers n'importe où, ou bien les personnes qui n'ont pas de domaine.

On peut en faisant une inscription dans la section "run" de la base de registre, lancer le script. (Je pense que cela peut même être fait durant la première installation du runtime. )

Il suffit de faire un fichier .reg avec ceci on le nome par ex :autoMaj.reg, ensuite double clique sur le fichier et l'inscription se fait seule.

Code :

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

1
2
3
4
 
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
"Maj"="\"C:\\MondossierMaJ\\MaJFrontal.vbs\""

Ceci a été testé pas de souci
a bientôt

[Papy Turbo]

Dans ce cas on abandonne aussi tout ce qui est sécurité...

Non, c'est pas ce que je veux dire.
2 choses complémentaires :
1- d'une part, je vois souvent des informaticiens (dans les S.I. plus que chez les indépendants, tiens donc ?) qui disent que les utilisateurs "font n'importe quoi", qu'il "faut tout blinder à mort", etc. Je me permets donc d'insister sur le fait que les utilisateurs ne sont pas des informaticiens, mais qu'ils sont aussi intelligents que nous. Ils peuvent écouter, comprendre, faire des erreurs (inévitable ) et apprendre le boulot d' "utilisateur qui gère son poste en évitant de refaire la même c...rie."
Ce qui veut dire : on met des garde-fous (pas d'accès direct à la fenêtre 'base de donnée', ni au code, ni en mode Design, etc.). On met même des mots de passe, mais on les leur donne (le logiciel leur appartient).
On ne peut jamais faire de système totalement blindé, donc on s'en tient à des mesures raisonnables financièrement et techniquement.

2- d'autre part, qu'est-ce qu'on veut protéger ici ? L'application elle-même + le script de mise à jour...
Si l'un de ces éléments est bousillé, on le répare en quelques minutes : simple récupération de la sauvegarde, sur autre serveur, au SI, ou chez le développeur. Bref, ça ne coûte quasi rien à réparer.
Contrairement à la base de données qui, elle, si elle n'est pas soigneusement sauvegardée, est une perte très lourde à réparer, si on peut retrouver les données perdues.

Ce que je veux dire c'est que, dans la réalité, jamais je n'ai eu le cas d'un utilisateur qui renomme un fichier ou modifie le script sans passer par la personne compétente. Et, si ça arrive, ça se répare simplement. Donc, je ne me pose pas ce genre de problèmes.
Par contre, rajouter des blindages et encore des blindages, ça introduit toujours des contraintes souvent désagréables.
En fait, je ne reçois quasiment que des demandes inverses des utilisateurs, du style "On veut que le mot de passe, au démarrage", soit une option. Par défaut, aucun mot de passe..."
OK. On a des solutions, avec de bons garde-fous. Sans plus. Tout le monde est content.

Le sujet des données sensibles (BDD), à protéger, est un tout autre sujet déjà abordé dans [Débat] Access 2007 : Microsoft abandonne la gestion de la sécurité utilisateurs.


Naphta : Super. Merci pour le script + .reg, je vais essayer de m'en servir (si le SI du client me laisse faire, mais, sur le poste utilisateur, avec ses droits, ça devrait passer.)
Question au spécialiste :
- si j'utilise un programme d'installation en VBA, sous Access, pour faire la prochaine install sur + de 20 postes, tu penses que je vais pouvoir lancer un

Code :

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

Shell "AutoMaj.reg"

pendant l'installation, sur le poste de l'utilisateur, pour inscrire cette entrée dans le registre ?

[Tofalu]

Ce que je voulais dire, c'est qu'une nouvelle version d'application, ce n'est pas forcément une plus jolie, plus sympa, plus fonctionnelle. Ca peut être aussi une corrective, une qui dégrade des droits d'un utilisateur, etc. Et dans ce cas, on est bien obligé de faire en sorte que l'utilisateur passe sur la nouvelle version.

Imagine que l'utilisateur avait des supers pouvoirs sur un formulaire avant et que du jour au lendemain il ne faut plus qu'il les ait ? Il ne va pas mettre longtemps à comprendre qu'en revenant à sa version antérieure et en zappant les MAJ il garde le contrôle.

D'autre part, si pour X raison le launcher vient à ne plus faire son boulot, il peut se passer des dizaines de MAJ avant que quelqu'un ne s'en rende compte ... Alors que si l'appli s'auto gère en complément, l'utilisateur aura vite fait de remonter l'information ...

Le launcher est indispensable puisqu'on ne peut pas copier l'application à chaud. Mais pour moi, ça me paraît pas suffisant.

Enfin toute les applications n'appartienne pas à l'utilisateur. Quand le développeur est interne à la société (et non prestataire), c'est le DSI qui a la responsabilité du fonctionnement. Si l'utilisateur à supprimé un fichier primordial, on dira souvent que c'est la faute de l'informaticien et non celle de l'utilisateur, fallait faire en sorte que ce soit inaccessible.

[naphta]

Bonjour,

Pour répondre à Tofalu, on peut ajouter un peu de code pour établir un journal des mises à jour, ce n’est pas très difficile et c’est une bonne idée par rapport aux casses pieds.

Je le répète il est très difficile d’arrêter un logon script et surtout de le supprimer.

Quant aux DSI ils sont en général preneurs de solutions qui leurs permettent de rester le plus près possible de la chaise.
Et puis comme le disent les chinois peu importe que le chat soit gris, blanc ou noir du moment qu’il ramène la souris.

Voici la V2

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
 
dim FrtenCours 'Frontal en cours d'utilisation
dim FrtMaj 'Frontal supposé MàJ
dim ladateorigine 'Date Frontal en cours
dim ladateMaj 'Date Frontal supposé MàJ
Dim FicdeSortie 'Fichier de Log
FicdeSortie = "G:\Distribution\Maj\LogdeMaJ.txt" ' Emplacement théorique du Fichier de log
 
'Emplacements physiques
FrtMaj = "G:\Distribution\Maj\LeFrontal.accdr" 'Frontal supposé MàJ
FrtenCours = "C:\ExploitFrontal\LeFrontal.accdr" 'Frontal en cours d'utilisation
 
if FichierExiste(FicdeSortie) = false then
	'Test si le fichier de log existe sinon création
	creelefichier(FicdeSortie)
End if
 
if FichierExiste(FrtMaj) = true and FichierExiste(FrtenCours) = true then
	'Test si MàJ nécessaire, si oui on copie et on trace dans le log
		ladateorigine = donneladate(FrtenCours)
		ladateMaj = donneladate(FrtMaj)
 
		if ladateMaj > ladateorigine then
			copieFrontal
			EcrituneTrace FicdeSortie,ladateMaj
		end if
	else
	 	wscript.echo "Il y a un pépin avec les emplacements ou les noms de fichier"
end if
 
function donneladate(kelbase)
'Connexion à une base et interrogation
	Set conn = CreateObject("ADODB.Connection")
	strConnect = "Provider=Microsoft.Ace.OLEDB.12.0;Data Source=" & kelbase & ";Persist Security Info=False;" 
	conn.Open strConnect
	LeSQL = "SELECT Version.ladate FROM Version"
	Set rs = conn.Execute(LeSQL)
	rs.movefirst
	donneladate=rs(0)
	conn.close
	Set conn = Nothing
end function
 
Function copieFrontal
'Copie du Frontal
	Set fso = CreateObject("Scripting.FileSystemObject")
	fso.CopyFile FrtMaj , FrtenCours 
	Set fso = Nothing
end function
 
Function FichierExiste(leFichier) 
    Dim filesys
    Set filesys = CreateObject("Scripting.FileSystemObject")
    If filesys.FileExists(leFichier) Then
        FichierExiste = True
    End If
End Function
 
Function EcrituneTrace(nomdufichierLog, DateMaJ)
	'Ici on écrit une trace dans le log
	Dim objFileSystem
	Dim objOutputFile
	Set objFileSystem = CreateObject("Scripting.fileSystemObject")
	Set objOutputFile = objFileSystem.OpenTextFile(nomdufichierLog, 8)
	objOutputFile.WriteLine(filelenomMachine & " mise à jour le " & Now & " avec la version du " &DateMaJ)
	objOutputFile.Close
	Set objFileSystem = Nothing
end function
 
function creelefichier(nomdufichierLog)
	'Ici on créé le fichier de log s'il n'existe point
	Dim objFileSystem
	dim objOutputFile
	Set objFileSystem = CreateObject("Scripting.fileSystemObject")
	Set objOutputFile = objFileSystem.CreateTextFile(nomdufichierLog, TRUE)
	objOutputFile.WriteLine("Traceur de mise à jour log du (" & Now & ")")
	objOutputFile.Close
	Set objFileSystem = Nothing
end function 
 
Function filelenomMachine
	'Ici on récupère le nom de la machine
	Dim NomdeBecane 
	set NomdeBecane = Wscript.CreateObject("Wscript.Network" ) 
	filelenomMachine = NomdeBecane.ComputerName 
end function

Explication :
On créé un log pour tracer les mises à jour avec :
le nom de la machine
le jour et l'heure de la mise à jour
et la date de la nouvelle version

plus tard on pourra faire un log au format csv exploitable sur Excel pour vérification
A bientôt

[Papy Turbo]

Tofalu, bonjour et, désolé, mais je ne partage pas ce point de vue.
Je n'ai jamais eu ton cas, parce que les droits des utilisateurs sont toujours stockés dans la base (cryptés ou pas). Ils changent par la décision du responsable qui a le seul accès, et ne nécessitent pas de mise à jour.

Pour moi, toutes mises à jour mineures sont des corrections de bugs, voire des ajouts de fonctionnalités mineures, sans impact sur la base de données.
Les mises à jour majeures se font (selon ma convention de nommage des fichiers et de numérotation des versions, mais c'est très souvent le cas partout, avec Access) lorsqu'il y a modif d'un champ, une table ou une relation, donc nouvelle base (dont le nom contient toujours le n° de version, pour éviter les mélanges), avec, bien sûr, les nouvelles fonctions/formulaires... qui utilisent ces nouvelles tables.

Maintenant, dans le cas ou ça se passerait comme ça, même si ton utilisateur a réussi à faire une copie de sauvegarde de l'ancienne appli (remplacée par la nouvelle et supprimée du serveur) et la réinstalle, du fait qu'une nouvelle BDD est en fonctionnement, tu peux très simplement empêcher ton application V2.0 de travailler avec une autre base que celle qui est à la version 2.0. Ton appli V1.x ne peut se connecter qu'à une base V1.x, donc elle ne démarrera plus.
Ou tout autre "N° de version d'appli" stocké en paramètre, dans la base de données, par toi seul. Et qui permettrait le même type de contrôle, même sur les versions mineures...

Sur le fond, tu touches du doigt ce dont je me méfie dans les rapports développeurs/utilisateurs : pourquoi leur prêter des intentions aussi négatives ? du moins tant qu'on n'a pas rencontré le problème en vrai, ni pu le résoudre par une simple discussion/explication.

Si l'utilisateur à supprimé un fichier primordial, on dira souvent que c'est la faute de l'informaticien

Moi, je serais toi, je changerais tout de suite d'employeur... Non, je rigole. En fait, je me mettrais à mon compte

Naphta, bon log
Le pinailleur de service suggèrerait juste : pourquoi ne pas tester/créer le journal à l'intérieur de la fonction EcritUneTrace() ? Pas besoin de créer de log si y a pas de mise à jour...

Sinon, tu me fatigues. Mine de rien, la nuit, ça
Je me pose la question de lancer le script sur des machines fixes ou peu mobiles et, comme mon propre poste, jamais éteint ??? Veille légère ou lourde, mais c'est tout, 5 à 6 jours sur 7.
Qu'est-ce qu'on peut trouver comme autre "évènement sytème" : à la sortie de veille ?

[Tofalu]

Maintenant, dans le cas ou ça se passerait comme ça, même si ton utilisateur a réussi à faire une copie de sauvegarde de l'ancienne appli (remplacée par la nouvelle et supprimée du serveur) et la réinstalle, du fait qu'une nouvelle BDD est en fonctionnement, tu peux très simplement empêcher ton application V2.0 de travailler avec une autre base que celle qui est à la version 2.0. Ton appli V1.x ne peut se connecter qu'à une base V1.x, donc elle ne démarrera plus.
Ou tout autre "N° de version d'appli" stocké en paramètre, dans la base de données, par toi seul. Et qui permettrait le même type de contrôle, même sur les versions mineures...

C'est justement ce que je préconisais depuis le début en plus de la solution de naphta

[naphta]

Bonjour,

Je n'avais pas testé la version avec traceur, c'est fait, ça fonctionne.
En réponse à Papy Turbo :
si le fichier log n'existe pas il est créé une seule fois.
Après on écrit par ajout successifs(append), même si on désire distribuer une nouvelle mise à jour, si pas de mise à jour pas d'écriture dans le fichier.

Sinon pour Tofalu, et si je puis me permettre, tu te prends trop la tête avec les casses pieds de service, personnellement j'en ai jamais connu.

Voilà pour ma part j'espère que je ne vais pas prendre du bide car je ne ferais plus autant de kilomètre.

A bientôt

[Papy Turbo]

J'ai bien compris le fonctionnement du log et sa création.
Je précise que je pinaillais , comme d'hab, en suggérant que le test ne soit pas effectué tous les jours, alors qu'il n'y a que quelques mises à jour par an, au pire une par mois...
Les démarrages de Windows sont déjà tellement lents

[naphta]

Bonjour,

Ici la réflexion de Tofalu

Imagine que l'utilisateur avait des supers pouvoirs sur un formulaire avant et que du jour au lendemain il ne faut plus qu'il les ait ? Il ne va pas mettre longtemps à comprendre qu'en revenant à sa version antérieure et en zappant les MAJ il garde le contrôle.

Il y a bien une solution pour régler le compte aux retissant et c'est simple.

Au démarrage du frontal on effectue une comparaison de version ou de date et on demande à l'utilisateur de se déconnecter puis se reconnecter afin que la mise à jour puisse se faire puis l'appli se ferme.

Un message bien explicite et lisible.

A+

[ilank]

Bonjour à tous,

je ne suis pas convaincu par la solution bacth de connexion et script VBS.
Ici, il suffit que le poste sur lequel l'utilisateur s'est connecté dispose d'une copie du frontal pour le mettre à jour. De plus, le script VBS fait référence en dur au nom complet des fichiers; ce qui paraît contraire à l'idée d'automatisation.

La mise à jour est censé être un service de l'appli, il est donc nécessaire que l'utilisateur ouvre le frontal et se logge pour autoriser la mise à jour. Une idée est d'utiliser les paramètres de la ligne de commande, sans paramètre le frontal s'ouvre normalement en vérifiant la présence d'une mise à jour sur le serveur. Avec paramètre, il se substitue au fichier local passé en paramètre.

[naphta]

Hola,

Cela fait plusieurs mois que j’utilise cette méthode. Les gens chez qui elle est en place gagnent du fric avec l’appli, les utilisateurs et les patrons ne tiennent pas spécialement à avoir la version -1 ou -8 car ce sont eux en général qui demandes les modifications.
Je rappelle que se sont de petits sites tout le monde se connait, si une édition genre OF ressemble à celle de la version -4 ça va se savoir !!
Le seul souci c’est l’utilisateur qui laisse son ordi allumé en partant chez lui avec l’appli chargée.

A+

[niko9600]

Hi,

En ce qui concerne les utilisateurs qui oublient de fermer l'appli, je fais un test sur le timer de mon form "Connexion à la base" (qui reste en permanence ouvert).
Si l'utilisateur n'as pas utilisé la base pendant 10min (par ex), un form s'affiche avec un compte a rebours de 20sec pendant lequel il pourra annuler la fermeture automatique si nécessaire.

[naphta]

Bonjour,

Ceci était ma première proposition, elle a été très critiquée c'est bien d'ailleurs.

Les mises à jour se font grâce au login script se trouvant sur le serveur de fichiers.
Ce script sert habituellement à la connexion des partages et éventuellement aux imprimantes partagées. J'ai inséré l'exécution d'un script VBS de mise à jour avec un log des stations qui ont la mise à jour.

Je préfère de loin l'alternative N° 2 où là la mise à jour est imposée sans script et sans connaitre le nom du frontal à mettre à jour.
L'utilisateur ne peut pas passer au travers d'une mise à jour, c'était le principal reproche de cette solution.

A+