Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Réseaux / Réplicats : tutoriels et explications ?
Hello...
Au risque de me faire huer pour cette question... Je pense avoir un problème de doigt et de cerveau... si, si, si...
Je me lance : Je ne trouve aucun tutoriel ni infos traitant des réplicats...(et je n'ose même pas vous dire depuis combien de temps je suis en train de chercher...)
Euh... Vous m'en voulez pas trop hein ??
Dernière modification par FRED.G ; 12/03/2007 à 12h47. Motif: Titre
Bonjour
en général ici les replica ne sont pas tres apprécié
Moi j'en utilise et pour l'instant tout va tres bien
si tu as des questions je peux essayé d'y répondre
Bah, en fait, ma question est assez simple... J'ai une application en réseau (frontal/dorsal) sur 3 postes.
Seulement, il y a deux nouveautés que je vais devoir prendre en compte bientôt...
1. Un commercial utilisant cette application doit passer chez les clients avec son portable, et il a besoin d'avoir accès aux informations... (j'ai lu que les réplicats pouvaient résoudre ce problème)
2. La société va s'agrandir, et il va y avoir deux magasins reliés entre eux par internet... C'est là que ça devient encore plus compliqué... Car dans l'absolu, il faudrait que les deux magasins soient reliés en "temps réels"... Et là, je ne sais pas trop comment m'y prendre... j'ai besoin de conseils...
Pour un portable , et c'est mon cas il n'y que lemploi de replica qui permet de résoudre le pb
Mais attention la marche arriere n'est pas possible.
Mais non nous ne sommes pas sectaire ici...en général ici les replica ne sont pas tres apprécié
Le réplica n'ayant pas d'équivalent (simple) quand il faut l'utiliser on le fait.
Le fait est qu'il augmente la taille des tables (insertion d'un N° GUI), mais bon... on a rien sans rien.
Pour la relation entre 2 sites via internet cela dépend de plusieurs facteurs :
Après cette analyse soit on choisi une connexion en temps réel, soit une connexion locale (copie des données cycliques), soit un système hybride.
- La quantité de données,
- Le type de connexion entre les données et l'interface,
- La fréquence de mouvement des données (ajout, suppression d'article dans un stock, changement de prix...)
- Le débit internet garantit (et non en crête comme la plupart de FAI le donne)
Cordialement,
Bonjour, merci pour vos réponses...
Loufab, pour te répondre :
1. La quantité de données : Et bien, ça dépend... Pour te citer un exemple, j'ai un calendrier d'intervention en semaine. Lorsque le technicien l'affiche, il doit afficher toutes les interventions de l'année en cours (et de celles passées également). j'ai donc une requête qui va chercher les infos dans plusieurs tables... Le calendrier devra afficher les infos des deux magasins...
2. Type de connexion entre l'interface et les données : Chaque magasin à un ordinateur qui sert de "serveur". J'ai mis serveur entre guillemets car c'est juste un pc qui est réservé au stockage de données, donc normalement, aucun utilisateur ne devra s'en servir... Il y a donc pour l'instant les tables sur ce serveur (dorsal), et chaque poste à son application (frontal). Le tout est lié par un routeur. Ca ressemble plus à un réseau domestique en fait...
3. La fréquence de mouvement des données : On va dire une moyenne de dix fiches clients à la journée entre la prospection et les magasins... Sachant que ce nombre va augmenter... Enfin, le patron l'espère !!!
4. Le débit internet garantit : Les magasins passent par une connexion internet d'environ 20 Mega en entrée et 1 en sortie (de mémoire)... Ca, ce sont les chiffres annoncé par le fournisseur...
Merci d'avance...
Vu le très -trop- faible débit (1 Mb/s on ne prend en compte que l'upload - comme si tu avais 10 fois moins de débit qu'un réseau en 10Mb/s) je te conseille :
- d'avoir recours au maximum à des tables temporaires pour toutes les données statiques ; celles qui ne bougeront plus ou occasionnellement (stock, tarifs, clients, planning passé) quite à faire les mises à jour la nuit.
- d'éviter les accès direct aux tables dans l'ihm.
- d'éviter les champs Mémo, Ole etc (en transit)
- d'éviter les zone de listes et listes déroulantes basées sur des selects
- de faire transiter le strict minimum en terme d'enregistrement et de champs.
- reparamétrer les timing ACCESS.
Pour l'infrastructure locale, vu les équipements actuel un 100 Mb/s est largement suffisant, avec du 1Gb/s c'est très confortable.
Il vaut mieux prévoir à l'avance la montée en charge (utilisateurs et données) c'est toujours mieux que de passer pour un charlot ou comme certains le font accuser le produit.
Dernière solution opter pour une connexion professionnelle donc plus musclée.
Regarde sur le MSDN il y a une foule de conseils et de réglages pour des cas comme le tien. A consommer sans modération.
Cordialement,
Hello...
Juste parce que j'ai l'esprit un peu lent...
Ca, j'ai compris... (comme les tables civilité, par exemple "Monsieur, Madame", etc...)- d'avoir recours au maximum à des tables temporaires pour toutes les données statiques ; celles qui ne bougeront plus ou occasionnellement (stock, tarifs, clients, planning passé) quite à faire les mises à jour la nuit.
Je ne saisis pas très bien, ici... Les tables contiennent les données... Comment éviter les accès aux tables ?- d'éviter les accès direct aux tables dans l'ihm.
Ca, ok...- d'éviter les champs Mémo, Ole etc (en transit)
La aussi, j'ai du mal... Par exemple, j'ai un historique qui affiche les commandes pour chaque client dans la fiche client...- d'éviter les zone de listes et listes déroulantes basées sur des selects
C'est effectivement la dessus que portait, entre autre, ma question d'origine... et donc, également, comment on utilise les réplicats ?- de faire transiter le strict minimum en terme d'enregistrement et de champs.
Alors là... Je patine dans la semoule...- reparamétrer les timing ACCESS.
En fait, pour prendre un exemple concret, et bien comprendre comment ça se passe :
J'ai une fiche client déjà créée depuis un bout de temps... Un commercial (en magasin) s'aperçoit qu'une erreur à été faite sur l'adresse de ce client... il la corrige... Jusque là, tout va bien...
Ce que j'aimerais savoir, c'est, par rapport à tout ce que tu m'as dit juste avant, où vont être stockées les données, comment elles vont transiter, est-ce qu'il est possible, une fois la correction effectuée, qu'un autre commercial d'un autre magasin voit la modif, etc... (merci d'avance)
Pour MSDN, j'ai visité, c'est vrai qu'il y a une foule d'infos...
Je ne pensais pas que les réseaux étaient aussi compliqués à mettre en oeuvre... Mais bon, quand on aime........ !!!
Salut (l'anti Star'ac, avec toi on est au moins 2)
Accès direct aux tables.
Evite de mettre le nom de la table directement dans la propriété source.
Evite également le select global, préviligie plutot le select enregistrement par enregistrement (pour les formulaires non continu) et pour ceux en mode continu restreint le nombre de record retourné.
Les listes déroulantes
chaque fois que tu ouvres un formulaire qui en contient il les charge toute, c'est là que le réseau est sollicité. Soit tu crées des tables temporaires, soit tu les charge au moment de leur consultation (lent pour l'utilisateur) soit tu utilises des listes partielles.
Timing se paramètre dans Outils/options. et pour certains param dans la BDR directement.
Code : Sélectionner tout - Visualiser dans une fenêtre à part Timing
Ce n'est pas trop le réseau qui est compliqué c'est plutot d'arriver à trouver un conscensus entre rapidité acceptable et ihm fonctionnelle.
C'est le problème des liaisons à faible débit. On prend toujours le upload comme référence car quelque soit la machine : elle envoie au maximum à ce débit.
A part d'avoir la base chez un provider qui accepte la techno MS auquel cas tu bénéficie de la vitesse du serveur. Le plus simple est encore de prendre une ligne professionnelle (Upload plus important).
En tout cas c'est de longues heures de mise au point et de tests en perspective.
Je n'ai pas mis en oeuvre de réplication dans ce cas pour te donner des conseils la dessus.
Ton retour d'expérience nous interesse. n'hésite pas à nous faire part de tes tests, constatations et découvertes.
Cordialement,
Alors déjà, la Star Ac' :!!! Voilà, ça, c'est dit !
Cette réalisation devrait avoir lieu au mois de septembre... Mais je m'y prends à l'avance parce que je n'ai jamais fait et que je n'y connais rien...Ton retour d'expérience nous interesse. n'hésite pas à nous faire part de tes tests, constatations et découvertes.
Le souci, c'est que je ne sais pas trop par où commencer... La, je termine la nouvelle version de la base (plus souple, plus évoluée, etc...) et par rapport à ce que tu viens de me dire (notament limiter les connexions réseau), je vais sans doute avoir à revoir certains détails...
La source de mes formulaires est tout le temps basée sur des requêtes, mais certaines de ces requêtes sont basées sur l'ensemble des enregistrements, c'est simplement pour trier que je les utilise... Donc, ça aussi, je vais devoir revoir...
Mais bon... Pour tout ça, c'est plutôt du domaine de la logique, là, ça ne me pose pas trop de problème d'arriver à atténuer au maximum les connexions... Au mieux, par exemple pour les historiques, je peux très bien créer un bouton qui permet à l'utilisateur de les afficher s'il en a besoin, comme ça, ceux-ci ne transitent uniquement que lorsqu'il le veut...
La où je rencontre d'autres problèmes, c'est donc au niveau technique... Les deux problèmes principaux étant :
1. de gérer le portable du commercial qui s'en va avec des données et reviens avec des modifications et des nouvelles données (c'est là que j'ai lu que les réplicats servaient à ça, je vais donc plancher la dessus et voir s'il existe d'autres méthodes)
2. de gérer les deux magasins et donc le flux de données...
Pour ce qui est du réseau, je pense effectivement que par la suite une ligne professionnelle sera mise en place... Mais pas dans un premier temps...
Bon... En tout cas, oui, je vais chercher... Je vous tiendrais au courant de ce que je peux trouver d'intéressant...
Merci...
Regarde sur le MSDN, notamment un article qui se nomme (ou doit se nommer) performance des bases ACCESS ou un truc comme ça.
J'y suis tombé dessus (
Hello,
Au risque de faire grincer les dents de quelques-uns... je potasse depuis l'autre jour sur les réseaux, les transferts de données, etc... Et je suis tombé sur un tuto (je ne sais plus de qui
A priori, ce que je cherche à faire, c'est "simplement" créer un projet access, et non plus une "simple" base de données...
Et d'apès ce que j'ai compris, en créant un projet (.adp), on obtient un vrai système client-serveur : SQL serveur ou MSDE en dorsal et Access en frontal... On peut même éventuellement utilser mySQL (si on a pas SQL Serveur, MSDE étant uniquement un runtime) si j'ai bien tout compris pour le serveur...
Enfin bref... Vu ce que j'ai lu, pourquoi certains disent-ils que Access n'est pas un vrai SGBD Client-Serveur ???
Ou alors, c'est que je n'ai rien compris...
Quand on parle d'access on parle avant tout du moteur Jet (moteur de base de données natif d'Access) soit par omission volontaire ou plus souvent par méconnaissance du produit.
Le moteur Jet n'est pas client/serveur.
Attention Sql Serveur livré (gratuitement) à partir de la version 2000 d'ACCESS n'est pas aussi performant que la version complète.
Cordialement,
Répondre avec citation
Partager