Discussion :

[seb92400]

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 ??

[Stargate SG1]

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

[seb92400]

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...

[Stargate SG1]

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.

[loufab]

en général ici les replica ne sont pas tres apprécié

Mais non nous ne sommes pas sectaire ici...

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 :

• 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)

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.

Cordialement,

[seb92400]

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 !!! Et qu'un commercial va faire de la route et ramener des données sur son portable... Pour ce qui est de la consultation et de la mise à jour de données sur une fiche gestion, c'est plusieurs fois par jour, mais en principe, ça n'aura lieu que du magasin principal ou il y a le responsable technique. Mais ça doit quand même rester possible de chaque poste au cas où... Et ce qui serait le must, c'est que dès qu'une fiche est saisie dans le magasin A, celle-ci soit être accessible quasi instentanément dans le magasin B. Pareil si on rentre un paimeent... Si celui-ci est rentré dans le magasin B, il faut qu'il soit visible après saisie dans le magasin A... etc...

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...

[loufab]

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,

[seb92400]

Hello...

Juste parce que j'ai l'esprit un peu lent...

- 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.

Ca, j'ai compris... (comme les tables civilité, par exemple "Monsieur, Madame", etc...)

- d'éviter les accès direct aux tables dans l'ihm.

Je ne saisis pas très bien, ici... Les tables contiennent les données... Comment éviter les accès aux tables ?

- d'éviter les champs Mémo, Ole etc (en transit)

Ca, ok...

- d'éviter les zone de listes et listes déroulantes basées sur des selects

La aussi, j'ai du mal... Par exemple, j'ai un historique qui affiche les commandes pour chaque client dans la fiche client...

- de faire transiter le strict minimum en terme d'enregistrement et de champs.

C'est effectivement la dessus que portait, entre autre, ma question d'origine... et donc, également, comment on utilise les réplicats ?

- reparamétrer les timing ACCESS.

Alors là... Je patine dans la semoule...


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........ !!!

[loufab]

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.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Timing

Timing se paramètre dans Outils/options. et pour certains param dans la BDR directement.

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,

[seb92400]

Alors déjà, la Star Ac' : !!! Voilà, ça, c'est dit !

Ton retour d'expérience nous interesse. n'hésite pas à nous faire part de tes tests, constatations et découvertes.

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...

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...

[loufab]

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 () il y a quelques mois. Très interessant.

[seb92400]

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 tellement je lis...) ou j'ai plus ou moins la solution à mon problème...

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...

[loufab]

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,