Discussion :

[Gulien]

Bonjour,

C'est mon premier message sur ce forum, je viens d'achever le livre d'autoformation de Windev 14, et je me pose une question :

Est-il possible de développer un logiciel que l'on peut à la fois compiler pour version monoposte (donc un executable tout seul sur un poste avec une base HyperFile classic)
et que l'on peut à la fois compiler pour version serveur (installation serveur, Hyperfile Client/serveur etc...)

J'ai l'habitude de 4D, où pour le même code, on peu compiler du monoposte ou du serveur, et intuitivement je ne trouve pas la solution pour faire ceci sous Windev ?

Peut-être en développant toujours la version monoposte, et en la transformant à chaque fois en version serveur ? (puis re-travailler sur la version mono ensuite)

Peut-être que ma question est totalement à côté de la plaque (je vais débuter mon appli. et je verrai bien), mais si vous aviez une réponse ça me rassurerait

Merci

[mogwai162]

D'abord une question souvent rituelle : Pourquoi faire ?

L'impression que j'ai est que tu n'a aucunement besoin de ça....

Mais rassure toi on peut via hdecritconnexion et hchangeconnexion transformer un accès prévu en hf/cs en hf classic.

[GSOFT-DOUZ]

bjr
comme il te dit mogwai162 et tu doit migrer ton analyse ver c/s (option analyse)
bon travail

[Gulien]

Désolé de répondre en retard,

En ce qui concerne les besoins : Si c'est primordial pour moi d'avoir une version mono et C/S.
J'édite un logiciel qui doit aussi bien être installé sur un poste mono (pour un privé par exemple qui n'a besoin que d'un poste) qu'un serveur avec plusieurs personne qui bossent dessus (partie secrétariat, compta, plusieurs privés, etc...).

J'irais même plus loin il faut aussi que je puisse héberger des serveur moi-même (en passant par un hébergeur) en hébergement normal ou mutualisé.

Donc il me faut 4 modes de fonctionnement.(puis aboutir à du SaaS avec WebDev...)


Donc la solution, c'est bien de tout développer en mono, et pour chaque version, passer en HyperFile C/S.
Et vice-versa pour reprendre une version mono via les outils que vous m'avez cité.


Merci de vos réponses

[david77320]

Je ne veux pas dire de co....rie mais il me semble que c'est à la création de la procédure d'installation que tu définis le type d'installation dont tu as besoin

[Gulien]

Oui, mais il y a possibilité de changer après (voir bouquin d'auto-formation que je n'ai pas sous les yeux là) , ensuite je ne savais pas si on pouvait changer dans les deux sens, et apparemment c'est faisable.

J'aurais bien aimé qu'on me propose "compiler en mono" ou "compiler en serveur", mais on ne peut pas tout avoir. C'est déjà très bien comme ça.

[david77320]

passé une version monoposte en multi poste puis vice versa ???

Si c'est ca ton besoin il t'est possible de changer le repertoire des données donc possible de passer de données local à données serveur

[=JBO=]

Bonjour à tous,

Je voudrais mettre l'accent sur la version de l'analyse, dont dépend l'application compilée.

[...] et tu doit migrer ton analyse ver c/s (option analyse)

Je crois que migrer une analyse HF Classic en une analyse HF C/S implique une nouvelle version de l'analyse et donc une nouvelle version de l'application.

Est-il possible de développer un logiciel que l'on peut à la fois compiler pour version monoposte (donc un executable tout seul sur un poste avec une base HyperFile classic)
et que l'on peut à la fois compiler pour version serveur (installation serveur, Hyperfile Client/serveur etc...)
[...]
Peut-être en développant toujours la version monoposte, et en la transformant à chaque fois en version serveur ? (puis re-travailler sur la version mono ensuite)

Si l'objectif est de développer une version unique de l'application (que tu pourras corriger et faire évoluer), à mon avis il faut éviter de migrer l'analyse.

Il serait plus sûr de la développer en HyperFile Classic seulement.
Et pour utiliser cette application avec une BD HyperFile Client/Serveur, au choix:

• dans l'application, utiliser la fonction HConnecte();
• dans l'application, utiliser les fonctions HDécritConnexion() et HChangeConnexion();
• dans l'éditeur d'installation, spécifier que les fichiers de données seront déployés en client/serveur

Pour ce qui est de l'éditeur d'installations, tu peux prévoir un premier scénario de déploiement Classic et un autre scénario de déploiement Client/Serveur.

Pour information, le centre de contrôle HyperFile permet aussi d'importer une base HF Classic dans une nouvelle base HF C/S.
_

[mogwai162]

Je crois que migrer une analyse HF Classic en une analyse HF C/S implique une nouvelle version de l'analyse et donc une nouvelle version de l'application.

Non mais oui quand même, Non dans la mesure ou une nouvelle version de l'analyse n'entraine plus obligatoirement la nécessite d'une nouvelle version de l'application. Mais oui puisque dans de nombreux cas, dont par exemple une modification de fichier ou de nom de connexion, le programme devra en tenir compte.

Il serait plus sûr de la développer en HyperFile Classic seulement.

L'inverse marche très bien également, je l'ai fait.

[=JBO=]

Bonjour à tous et à mogwai162 plus particulièrement.

Merci mogwai162 d'avoir précisé que l'on peut se connecter indifféremment de Classic vers C/S et réciproquement.
En fait, mon conseil (analyse pour BD HF Classic) était plus pratique que technique.

En effet, si tu développes une application à partir d'une analyse prévue pour HyperFile C/S, tu seras probablement tenté de faire appel à des fonctionnalités spécifiques au client/serveur... et l'application ne sera plus utilisable en l'état pour basculer sur une BD HF Classic.

C'est un risque que tu ne coures pas si tu cibles immédiatement une BD HF Classic.
_

[mogwai162]

C'est un risque que tu ne coures pas si tu cibles immédiatement une BD HF Classic.
_

Euh... oui c'est plutôt vrai

[Bowen]

Et...
si ton problème est seulement d'avoir les données sur un seul poste, pourquoi ne pas installer le serveur HF quand même ?
ça marche très bien, et ça simplifie tout !

Pas de problème pour faire fonctionner le programme, que le serveur soit distant, local, dans une autre pièce, à l'autre bout d'un VPN...

Je ne vois pas l'intérêt de rester sur un HFClassic, alors que le HF/CS peut fonctionner pour tous ces cas.

[mogwai162]

si ton problème est seulement d'avoir les données sur un seul poste, pourquoi ne pas installer le serveur HF quand même ?
ça marche très bien, et ça simplifie tout !

J'y avais bien pensé mais j'ai pas osé lui proposer parce que si c'est un poste client, il est très facile ensuite à l'utilisateur d'aller bidouiller les fichiers

[Bowen]

Aussi facile que si c'est des fichiers classic, je vois pas la différence.
Les fichiers HF/CS ont exactement la même structure que les classics, ils s'ouvrent donc avec le centre de contrôle HF, ou le WDMap tous les deux. Mais rien n'empêche de protéger le tout :

• Mot de passe sur le serveur HF
• Mot de passe sur les fichiers
• Et pour les paranos, cryptage de la connexion

[mogwai162]

Oui mais sur un poste client tu n'as pas wdmap et tu n'auras le centre de contrôle HF que si tu es en HF/CS. Cqfd.

[Bowen]

Il ne faut pas confondre le Centre de contrôle HF, et le moteur HF.
En client-serveur, le moteur HF est effectivement toujours présent. L'ensemble (Moteur + Fichiers) représente le serveur HF.
Le moteur, c'est le programme Manta.exe que tu trouves à la racine du dossier où tu installes ton serveur. Ce programme est lancé en service.

Le Centre de contrôle HF c'est autre chose.
C'est un peu l'équivalent client-serveur du WDMap. Il permet d'accéder aux données en interrogeant le service Manta.exe.
Il n'est pas du tout nécessaire d'installer le Centre de contrôle HF sur le poste où on installe un serveur. (j'aurais même tendance à le déconseiller, pour les raisons de sécurités auxquelles tu pensais.)

[EDM-TAHITI]

Hello,
pour parer les soucis entre monoposte et multiposte (ou utilisateur), je vous propose une ligne de commande

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
//
// ctrl mono-multi
// varaibles globales projet
ModeExe est un entier = 0
//
selon ModeExe
     cas 0 
         // mode mono utilisateur
         hblocagetotalefichier....
 
     autres cas
         // multi utilisateurs, poste, bref comme on veut
         hdebloquetotalfichier...
          // on gere apres les blogage soit en auto, soit en manuel
 
fin
//
// je mets un selon car après, si l'imagination s'en mele, on peut avoir un blocage selon le nombre de connexions, etc....

le oprincipe est d'avoir aussi un accès sur C/S en utilisateurs qui ne peuvent pas accéder au gestionnaire de bases
Admin<> utilisateurs. Après, on travaille sur les droits de la bases. Je vous invite a regarder les possibilités énormes que le serveur manta et le gestionnaire peut faire

[Gulien]

Merci beaucoup pour toutes vos réponses

A priori si je suis vos dernières interventions, il vaudrait mieux ne développer qu'en Client/Serveur, les centres de contrôles et compagnie, pouvant ne pas être installés.

et donc installer un Client/Serveur même sur les postes mono, en ayant des routines dans le code pour voir si la licence d'utilisation par exemple correspond à une mono ou une serveur, combien de postes etc...

C'est peut-être pas mal aussi si le client veut passer de mono à serveur plus tard...

J'ai l'impression que ça va être la partie la plus compliquée de l'application en fait :p

[Bowen]

Partie compliquée je sais pas.
Le mieux, c'est de développer comme si il y avait plusieurs personnes en permanence (test de lecture ok, test de maj effectuée, que se passe-t-il si l'info a été mise à jour par quelqu'un d'autre entre ma lecture et mon écriture ?
Et tout ça fonctionne très bien, même quand on est tout seul.
(le contraire n'est pas vrai)

[Gulien]

Partie compliquée je sais pas.
Le mieux, c'est de développer comme si il y avait plusieurs personnes en permanence (test de lecture ok, test de maj effectuée, que se passe-t-il si l'info a été mise à jour par quelqu'un d'autre entre ma lecture et mon écriture ?
Et tout ça fonctionne très bien, même quand on est tout seul.
(le contraire n'est pas vrai)

Ça ma l'air effectivement d'être la meilleur solution a mettre en œuvre.
Vu que je ne suis pas encore rompu à Windev, le but du jeu pour moi va être de discerner ce qui est faisable automatiquement avec les outils Windev de ce qui doit être développé sois-même.
En ce qui concerne les accès concurrentiels justement par exemple...