4D Server : Mise à jour auto des Clients?

Bonjour,

Existe-t-il pour 4D Server un mécanisme permettant de mettre à jour automatiquement les 4D Clients ?
Ex : passer de 4Dv17.0 vers 4Dv17 Hotfix 4 ? (je ne parle pas des “Ressources”, mais bien de l’application 4D)

Ou doit-on toujours mettre à jours tous les clients “manuellement” ou via Remote Desktop quand c’est possible ?

Je n’ai rien trouvé dans la documentation 4D Server à ce propos, mais j’ai peut-être mal cherché…

D’avance merci

Bonjour Luc,

Oui c’est possible depuis le R15+

Voir : https://kb.4d.com/assetid=77598

Et bonne année

Bonjour,

La mise a jour des clients existe déja en V13. Il faut pour cela générer une application. Dans l’onglet client serveur on peut spécifier le chemin de l’appli PC et MAC.

Sinon, lien vers les clé XML si on utilise la commande pour générer une application (Générer Application)

https://doc.4d.com/4Dv17R2/4D/17-R2.1720/4D-Cles-XML-BuildApplication.100-3929018.fe.html

Si la question c’est de mettre a jour les 4D en mode dév, là je n’ai pas de solution.

Cordialement,

Bonjour Maurice et Meilleurs Voeux également pour toi et tes proches.

je viens de télécharger la NT. Ca à l’air assez complexe. Il faut que je lise cela à tête reposée et fouille un peu dans l’exemple donné.
Merci en tous cas.

je crois que je me suis fait mal comprendre…

ce n’est pas le code de l’appli faite avec 4D qu’il faut mettre à jour sur les postes clients, mais bien 4D lui-même lorsque celui-ci change de version sur le Serveur.

Par exemple, on passe 4D Server de v17 en v17 hotfix4 —> il faut passer sur tous les postes clients pour installer 4D monoposte en version 17 hotfix4. (ou le faire en auto avec les fonctions de Remote Desktop sur Mac quand c’est possible).

C’est possible avec une base compilée (uniquement) et les clés XML de
rang de version

: Doc 4D

Cette clé
(<https://doc.4d.com/4Dv17/4D/17/4D-Cles-XML-BuildApplication.100-3787
81.fe.html>CurrentVers>) permet de spécifier le numéro de version
courant de l’application générée.
Si les clés RangeVersMax et RangeVersMin ne sont pas utilisées, ce
numéro est uniquement informatif. Si ces clés sont utilisées,
l’application Serveur lira ce numéro afin de déterminer si le Client
appartient à l’intervalle défini et est donc autorisé à se connecter.

A chaque connexion d’un client il vérifiera s’il est dans les rangs autorisés sinon il demandera la mise à jour du client.

Personnellement, je ne met jamais à jour seule la base (.4DC) sans mettre à jour la version des clients et du serveur. Apres chacun fait ce qu’il veut, mais il viendra pas pleurer après que cela ne marche pas comme il faut… :roll:

La mise à jour des clients peut se faire ainsi depuis la v15 jusqu’à la v17 inclue.

Donc, pour ton cas: pour passer un client en v17 vers un client en v17HF4 c’est possible.

Bonjour,

C’est bien ce que je sous entend dans mon message.

Les mises à jour automatiques pour moi c’est pour des base enginées (donc compilée, autonomes, fusionées avec 4D engine ou 4D server).

Je ne pense pas que cela existe pour un 4D monoposte qui se connecte au serveur distant (via se connecter au serveur distant) avec une version potentiellement utilisable en interprété.

Il faut relire la doc https://doc.4d.com/4Dv17/4D/17/Finaliser-et-deployer-les-applications-finales.200-3743431.fr.htmlici> :expressionless:

Bonjour et merci,

la base du client n’est pas compilée car les modifications sont quotidiennes et avec 25 postes connectés, on ne va pas demander à chacun de redemarrer plusieures fois par jour…

Comme pas de probleme de vitesse, juste une vérification du code.
Ce n’est sans doute pas la façon la plus optimale de faire fonctionner 4D, mais c’est la plus souple en tous cas.

D’autre part, le génétateur d’applications ne fonctionne que sur 4D Monoposte (voir doc développement). Or cette base est uniquement utilisée en 4D Server.

merci en tous cas d’avoir cherché…

Bonjour,

: Luc STELL

la base du client n’est pas compilée donc de nombreuses nouvelles fonctionnalités ne seront pas accessibles à votre client …

: Luc STELL

les modifications sont quotidiennes … plusieures fois par jour…
donc les modifications sont faites en direct, donc sans aucun test … c’est un choix.

: Luc STELL

D’autre part, le génétateur d’applications ne fonctionne que sur 4D
Monoposte Le générateur d’application s’utilise sur le poste qui prépare l’application. Ce n’est pas pour autant qu’il ne sait pas générer une application client/serveur.

Cordialement,

Bonjour Olivier,
dans la théorie, tout est merveilleux…
Mais au final ce sont les clients qui font les choix en fonction de leurs besoins et de leur environnement :mrgreen:
Beaucoup d’utilisateurs se contentent également de 5% des possibilités d’Excel ou de Word…tout en sachant qu’ils pourraient en faire plus.
Meilleurs Voeux pour 2019

Bonjour Luc,
en Savoie on y songe également. Si la copie d’un 4D client dument zippé du serveur vers le client ne me semble pas poser de problème, j’en vois d’autres lesquels je sèche un peu :

  • ça oblige à “anticiper” l’install de la version client avant de mettre à jour le serveur ; si par exemple je suis en v17r2 et que je prévoie de passer le serveur en v17r3, je ne pourrai faire cette copie qu’en client r2 avant (sans quoi je ne pourrai plus me connecter…). En outre il va forcément y avoir co existence des 2 4D clients sur le poste client pendant un temps, pas terrible.
  • je doute que le système ne me fasse pas ch… jusqu’à la gauche pour des problèmes de droits quand il s’agira d’installer l’exécutable

Sans compter que le zip n’est pas signé sur macOS… :twisted:

Mais ceci dit, je ne vois pas ce qui empêcherait 4D de fournir une mise à jour des clients y compris pour des bases non compilée. Apres tout c’est une connexion entre une application 4D (4D client) et une autre application 4D (4D serveur). Il faudrait fournir le client en archive avec le serveur 4D cela alourdirait la distribution du serveur; mais bon, on a rien sans rien.

La mise à jour en zip ne pose pas de problème à macOS :wink:

Si ton application n’est pas signée à partir de macOS 10.12, tu risques d’avoir des problèmes (https://www.youtube.com/watch?v=gNI9a-K1JoUY’en a qu’ont essayé, ils ont eu des problèmes !>)

Bonjour Arnaud,
pour l’instant on utilise la fonction de distribution d’applications de Apple Remote Dektop, car on a une grande majorité de Mac.
Ca marche bien, mais on doit attendre que les clients soient déconnectés de 4D (le soir) et laissent leur Mac allumé, y compris dans une dizaine de filiales connectés en VPN.

Tes remarques sur le poste client sont judicieuses. Peut-être qu’un Applescript avec temps d’attente lancé lorsque l’on quitte 4D permettrait de remplacer le programme par la nouvelle version, mais quid des PC/Windows ?

Il existe bon nombre d’applications qui ont la fonction “installer et redémarrer” pour les mises à jour. Faudrait peut-etre voir quels mécanismes y sont utilisés.

mais pour l’instant ce n’est pas “bloquant”, c’était juste une question :wink:

: Matthieu LAMPERIERE

La mise à jour en zip ne pose pas de problème à macOS :wink:
Plus sérieusement :-|, tu devrais relire cette https://kb.4d.com/assetid=78153note>
Seuls les .dmg sont signables; c’est pas pour rien que 4D les diffusent ainsi…

: Luc STELL

Peut-être qu’un Applescript avec temps d’attente lancé lorsque l’on
quitte 4D permettrait de remplacer le programme par la nouvelle
version, mais quid des PC/Windows ?
Je me méfie un peu d’applescript. À une époque (v2003, le chemin du data était une ressource), j’avais écrit un script qui prenait le relais quand le serveur devait être mis à jour : dans 4d server, je fixe le chemin du data dans le futur 4DC, je lance le script et je quitte ; le script lancé attend que le quit soit effectif puis relance le nouveau 4DC. Simple… sauf que l’applescript pouvait se vautrer sur l’attente de façon parfaitement aléatoire mais suffisamment fréquente pour que je jette l’éponge. Un standalone 4D dédié à ça serait beaucoup plus fiable !