S.O.S acces sous reseau
Résolu
louiza81
Messages postés
3
Date d'inscription
dimanche 17 septembre 2006
Statut
Membre
Dernière intervention
19 septembre 2006
-
17 sept. 2006 à 11:25
vrachid Messages postés 109 Date d'inscription lundi 6 mars 2006 Statut Membre Dernière intervention 5 octobre 2011 - 30 mars 2008 à 19:25
vrachid Messages postés 109 Date d'inscription lundi 6 mars 2006 Statut Membre Dernière intervention 5 octobre 2011 - 30 mars 2008 à 19:25
4 réponses
yopai_v
Messages postés
47
Date d'inscription
jeudi 7 septembre 2006
Statut
Membre
Dernière intervention
21 avril 2010
18 sept. 2006 à 23:23
18 sept. 2006 à 23:23
Bonjour,
"une application sous reseaux"... c'est un petit peu vague tout ça.
Selon la taille de ce que tu veux faire, tu peux :
- soit faire simplement une application qui se connecte à une base de
données distante (je connais très peu access, mais de mémoire il
fonctionne avec des fichiers, donc il suffit d'accéder au .mdb distant
- au pire en connectant un lecteur réseau, du style
Z:\dossier\mabase.mdb)
- soit créer une application client/serveur, c'est-à-dire :
* un exécutable "serveur", qui sera capable de recevoir
des instructions et de les interpréter (en utilisant entre autres une
connexion à la base de données)
* un exécutable "client" qui, sous la houlette de l'utilisateur, enverra les ordres au serveur.
Pour ça, je te conseille le couple TIdTCPServer / TIdTCPClient (Delphi
6 ou 7), qui est capable de gérer des messages simples et de coder
directement un événement derrière chaque message.
L'avantage de cette architecture est qu'elle soulage le poste client
(qui se contente d'effectuer l'affichage), et que le gros du traitement
est effectué par le serveur.
Ca n'empêche pas d'avoir la base de données sur une machine séparée - tu as alors une application trois-tier.
Je n'ai pas de bouquin à te conseiller, c'est bien dommage mais c'est comme ça :-)
Bon courage
"une application sous reseaux"... c'est un petit peu vague tout ça.
Selon la taille de ce que tu veux faire, tu peux :
- soit faire simplement une application qui se connecte à une base de
données distante (je connais très peu access, mais de mémoire il
fonctionne avec des fichiers, donc il suffit d'accéder au .mdb distant
- au pire en connectant un lecteur réseau, du style
Z:\dossier\mabase.mdb)
- soit créer une application client/serveur, c'est-à-dire :
* un exécutable "serveur", qui sera capable de recevoir
des instructions et de les interpréter (en utilisant entre autres une
connexion à la base de données)
* un exécutable "client" qui, sous la houlette de l'utilisateur, enverra les ordres au serveur.
Pour ça, je te conseille le couple TIdTCPServer / TIdTCPClient (Delphi
6 ou 7), qui est capable de gérer des messages simples et de coder
directement un événement derrière chaque message.
L'avantage de cette architecture est qu'elle soulage le poste client
(qui se contente d'effectuer l'affichage), et que le gros du traitement
est effectué par le serveur.
Ca n'empêche pas d'avoir la base de données sur une machine séparée - tu as alors une application trois-tier.
Je n'ai pas de bouquin à te conseiller, c'est bien dommage mais c'est comme ça :-)
Bon courage
louiza81
Messages postés
3
Date d'inscription
dimanche 17 septembre 2006
Statut
Membre
Dernière intervention
19 septembre 2006
19 sept. 2006 à 08:58
19 sept. 2006 à 08:58
merci beaucoup..........
Utilisateur anonyme
19 sept. 2006 à 23:57
19 sept. 2006 à 23:57
Salut
Arff il y a quelques betises dans les explications de yopai_v ^^
°Les deux types qu'il t'a souligné ne dépendent pas de la taille de ce que tu veux faire mais de ce que tu veux faire:
°Le serveur ne fais pas tout le travail avec Indy :
*Un serveur est le poste sur lequel on se connecte. Le client est le poste qui se connecte.
*Le dialogue CLient/Serveur avec Indy n'est pas unilatéral comme le suppose yopai. Il est parfaitement possible d'envoyer des commandes dans le sens Serveur->CLient. Par exemple un download est parfaitement faisable. Mais on va dire que les commandes Serveur->client sont moins évidentes et pas documentées. Un de ses jours je ferai un exemple complet d'échanges bilatérals client/serveur.
*Indy est bloquant : la main n'est pas rendue. Cependant il est possible de palier à ce probleme pas une procedure multithread ou par un antifreeze.
Voila pour les petites précisions ^^
@+
Arff il y a quelques betises dans les explications de yopai_v ^^
°Les deux types qu'il t'a souligné ne dépendent pas de la taille de ce que tu veux faire mais de ce que tu veux faire:
°Le serveur ne fais pas tout le travail avec Indy :
*Un serveur est le poste sur lequel on se connecte. Le client est le poste qui se connecte.
*Le dialogue CLient/Serveur avec Indy n'est pas unilatéral comme le suppose yopai. Il est parfaitement possible d'envoyer des commandes dans le sens Serveur->CLient. Par exemple un download est parfaitement faisable. Mais on va dire que les commandes Serveur->client sont moins évidentes et pas documentées. Un de ses jours je ferai un exemple complet d'échanges bilatérals client/serveur.
*Indy est bloquant : la main n'est pas rendue. Cependant il est possible de palier à ce probleme pas une procedure multithread ou par un antifreeze.
Voila pour les petites précisions ^^
@+
vrachid
Messages postés
109
Date d'inscription
lundi 6 mars 2006
Statut
Membre
Dernière intervention
5 octobre 2011
30 mars 2008 à 19:25
30 mars 2008 à 19:25
décidément tu ne fais que enguler les gens et critiquer leur éfforts, ça t'arrive de donner des réponses claires et éclairantes sans tout autant infliger des corrections mal formulés aux pauvre innocents qui ne cherchent qu'à promouvoir leurs éfforts ?????