application reseau
Stagiaire WDF
Inscrit:
15/11/2005 05:20
Post(s): 25
salut a tous

j ai dev. une application monoposte. je voudrai l utiliser en reseau quelles modifs dois je faire ?

merci de votre aide
avi

Contribution le : 01/12/2007 17:23
Créer un fichier PDF de la contribution Imprimer


Re: application reseau
DSI WDF
Inscrit:
12/09/2004 11:07
De aude
Post(s): 279
bonjour,
Soit vous gardez vos fichiers en HF et vous déployer votre intall en mode réseau en paramétrant le chemin d'accès au fichiers de l'application ou en le choississant lors de l'intallation sur la poste client, soit vous utilisez des fichiers HF/CS avec l'installation du serveur WINDEV.
N'oubliez pas les codes de raffraichissement si plusieurs utilisateurs sont sur l'application en même temps.

Espérant avoir apporté un bout de réponse.

Contribution le : 02/12/2007 10:57
_________________
...
Créer un fichier PDF de la contribution Imprimer


Re: application reseau
Stagiaire WDF
Inscrit:
15/11/2005 05:20
Post(s): 25
merci Toco pour ta reponse

je vais garder fichiers HF mais tu veux dire quoi par "codes de raffraichissement"?

merci
avi

Contribution le : 02/12/2007 12:31
Créer un fichier PDF de la contribution Imprimer


Re: application reseau
DSI WDF
Inscrit:
12/09/2004 11:07
De aude
Post(s): 279
Il s'agit en général d'une procédure locale qui permet de mettre à jour les données sur les différents postes.
Elle est générée lors de la création de fenêtres en RAD.
Voir les exemples.

Bon courage

Contribution le : 03/12/2007 08:57
_________________
...
Créer un fichier PDF de la contribution Imprimer


Re: application reseau
Animateur WDF
Inscrit:
26/06/2002 16:24
De wdforge.org
Post(s): 2822
Bonjour Aviasoft.

Votre application monoposte, pour fonctionner en réseau, doit s'assurer que les ordres effectués par les utilisateurs n'entrent pas en conflict.

Le conflict mageur est la tentative d'écriture : deux utilisateurs tentent de modifier une même donnée a un même instant.

Si vous utilisez le RAD, il gère ce cas de la manière suivante : le blocage est effectué uniquement au moment de l'écriture (validation de la fiche). C'est une possibilité suffisament admise pour avoir fait ce choix.

Maintenant, la plus grande différence se situe dans le déploiement de votre projet. L'installation 'avec mise à jour des données sur le réseau' consiste à déposer la base de donnée sur un serveur de fichier (un lecteur partagé du réseau) et les applicatif sur les postes de travail.

En réalité, une copie de l'installation est déposée sur un lecteur partagé du réseau. L'installation des postes doit alors être efectuée depuis cette copie (et non le support qui a installé le 'serveur').
En effet cette copie comporte le renseignement qui indiquera aux version 'poste de travail' la localisation des données sur le serveur.
Par conséquent il est important, pas obligatoire mais nettement plus pratique, que tout les postes partage le même chemin sur le serveur pour accéder aux données.

La mise à jour est alors simple : on met, depuis un poste de travail, à jour l'installation serveur (l'installation des postes est alors remplacée sur le serveur), puis chaque poste lance la mise à jour (depuis celle sur le serveur). Le premier assure alors la mies à jour automatique des données.

Cette architecture comporte toutefois des limites :
- L'accès aux données passe par le réseau. Cela ajoute un risque considérable dans la communication exécutables-données. En effet un simple problème dans le réseau et la base de données se trouve dans une situation instable.
- le réseau est un vecteur 'lent' pour acheminer les données .

Longtemps, la seule alternative a été l'installation en mode 'Terminal Server' (Windows TSE ou citrix). Là le serveur est à la fois serveur d'application et de données. Les postes se connectent aux serveur via un bureau distant (protocole ). Si la solution est plu chère (dimension du serveur et licences spécifique du service Terminal Serveur), elle est nettement plus robuste car seul les affichage et information de souris/clavier transitent sur le réseau (local ou distant). Le serveur est en charge tant de l'exécution du programme que de l'accès aux données qui sont alors locale. L'installation du projet est alors un simple installation classique. La compilation doit dimplement suporter l'exécution multiple sur le serveur. La partie réseau est alors dévolue au service Terminal serveur.

Enfin, depuis Hyperfile C/S, il est possible de conserver l exécution sur le poste de travail et la gestion de l'accès aux données sur le serveur. Le service Client/Serveur du moteur HyperFile C/S est piloté par un port TPC/IP sur le serveur en charge des connumincation entrantes/sortantes sur la base. De la même manière le serveur devrais comporter un serveur http/ftp pour que les postes de travail puissent mettre à jour l'exécutable. L'opération de mise à jour des données est effectuée lors d'une mise à jour de l'installation sur le serveur.

Bien cordialement.

Contribution le : 03/12/2007 15:11
_________________
R&B
Contact, CV.
Créer un fichier PDF de la contribution Imprimer



 Haut   Précédent   Suivant




Enregistrer votre réponse
CompteNom   Mot de passe   Authentification
Message:


Vous ne pouvez pas débuter de nouveaux sujets.
Vous pouvez voir les sujets.
Vous ne pouvez pas répondre aux contributions.
Vous ne pouvez pas éditer vos contributions.
Vous ne pouvez pas effacez vos contributions.
Vous ne pouvez pas ajouter de nouveaux sondages.
Vous ne pouvez pas voter en sondage.
Vous ne pouvez pas attacher des fichiers à vos contributions.
Vous ne pouvez pas poster sans approbation.

[Recherche avancée]


Connexion
Menu
Chercher WDForge
Chercher Web
Partenaires
Visualiser tous les Partenaires...
WinDev, WebDev, WinDev Mobile et HyperFile sont des marques déposées par PCSoft. |  Voter |  Legal |  Contact |   XOOPS 2.0.13.2