Access en réseau

[Secco]

Bonjour,

J'aimerais avoir vos avis sur la question Access en réseau.

Là où je bosse, notre BDD contient pas loin de 135 tables. Une bonne centaine sont des tables "temporaires" qui peuvent rester sur chaque poste, mais les tables les plus importantes, environ 25, sont sur le réseau, en tant que tables liées. De plus, assez régulièrement (à chaque Mise à jour du code des formulaires), les employés doivent retélécharger la base, ou au moins, la partie formulaire, de plus, ils arrivent que ça rame, et je pense que ça arrive lorsque les employés "utilisent" les mêmes tables simultanément, mais ça j'en suis pas sure !

Bref, j'aurais aimé savoir comment ça se passe pour ceux qui utilisent Access en réseau, avec un grand nombre de table, assez lourde. Et surtout, si vous aviez des pistes pour organiser ça au mieux.

Je vous remercie des témoignages que vous pourrez peut-être apporter,

Secco

[jpcheck]

Salut,
je recommande de stocker les données sur une base de type SQLServer ou autre, et d'utiliser des liens ODBC pour se connecter aux tables.
La gestion des bases en réseau (multi-utilisateur) est très bien décrite dans l'article de Dolphy35
http://dolphy35.developpez.com/artic.../basesreseaux/

[Secco]

Merci, en effet, tuto très intéressant, je pense que la personne qui a fait la bdd avant moi a du pas mal s'en inspirer... mais sur le principe, est ce que vous ça marche bien ? J'entends par là, jamais la base ne rame ?

Ou bien n'y a t il personne qui utilise Access en réseau...

[naphta]

Bonjour,

Pour access en réseau il y a la théorie et la pratique, et la pratique n'est pas toujours dans "les bonnes pratiques" enseignées par nos profs.

fruits de mon expérience :

- connexion aux tables liées avec une unité logique pas de nom UNC
- quand il faut une mise à jour simple ou calculée je le fais par le code
- les formulaires liés à des requêtes ou des tables au premier affichage en lecture seule et ce par le type de connexion "recordsertype", ici cela permet d'éviter la gestion des conflits car 9 fois sur 10 les utilisateurs font de la consultation.
- les listes d'enregistrements dans un listview par un recordset en lecture seule.
- timing réglé à 30 secondes pour les modifications, (souvent les utilisateurs ouvre un enregistrement puis ils téléphonent pour savoir si le bébé va bien)
- en définitive éviter les ouvertures avec le recordset en dynamique
- access aime bien la mémoire vive, faut pas hésiter à gonfler les bécanes jusqu'à 4 giga de mémoire, j'ai constaté de très nettes améliorations car access met tout en mémoire.
- du gigabit en réseau, bof.
- les connecteur DAO à l'instar de ADO parait-il, mais là j'ai pas vraiment constaté de vrai changement.
Voilà, il y a des recommandations pour cela chez Microsoft, pas beaucoup et très peu efficaces.

Le passage à SQL ne rend pas la base plus rapide au contraire.
De toute façon le principe est simple au lancement d'access, le frontal pompe un maximum de données et les tamponnes dans la mémoire du poste.

a+

[Secco]

Salut,

Tout d'abord merci d'avoir pris le temps d'exprimer ton experience, c'est très instructif, cependant, il y a quelques points que je n'ai pas très bien compris.

Envoyé par naphta

- connexion aux tables liées avec une unité logique pas de nom UNC

Je n'ai pas trop compris, peux tu développer ce point ? Connexion avec une unité logique ?

Envoyé par naphta

- les formulaires liés à des requêtes ou des tables au premier affichage en lecture seule et ce par le type de connexion "recordsertype", ici cela permet d'éviter la gestion des conflits car 9 fois sur 10 les utilisateurs font de la consultation.
- les listes d'enregistrements dans un listview par un recordset en lecture seule.

Je n'ai rien trouvé concernant le recordsertype (ou recordsetype en cas de faute de frappe), si j'ai bien compris ça renvoie les données des tables en lecture seule et donc ne permet pas de récupérer la valeur ? Idem pour la listview ?

En tout cas, je vais prochainement prendre le temps de creuser tout ça pour optimiser notre base et vraiment tous les conseils sont les bienvenus et les exemples...

Encore merci à tout ceux qui se pencheront sur la question !

[naphta]

Bonjour,

Si l'on a une archi Frontal/Base de données avec tables liées la base de données doit-être plutôt accessible avec une unité logique c'est à dire un G: ou K: au lieu de \\serveur\repbase (nom UNC).

- les formulaires liés à des requêtes ou des tables au premier affichage en lecture seule et ce par le type de connexion "recordsertype", ici cela permet d'éviter la gestion des conflits car 9 fois sur 10 les utilisateurs font de la consultation.

le recordsertype permet de passer du mode lecture seule à lecture écriture au cas où l'utilisateur voudrait écrire petit inconvénient lorsque l'on fait cela le formulaire revient au premier enregistrement puis à celui que l'on veut modifier. Il spécifie type de jeu d'enregistrement, 0, 1 ou 2.
Si l'on diminue la gestion des conflits on améliore sensiblement l'accès au infos

RecordsetType

- les listes d'enregistrements dans un listview par un recordset en lecture seule.

On a souvent à lister des enregistrements comme liste des factures ou devis pour tel ou tel client par exemple, l'utilisateur double-clique sur la ligne qui l'intéresse pour visualiser la pièce.

Ici je le fais dans un listview avec un recordset en lecture seule.

Le tuning d'une nouvelle base avec plus de 10 utilisateurs en réseau peut durer jusqu'à un an.

Voila en résumé les points les plus efficaces sont la mémoire et l'accès aux données le plus souvent possible en lecture seule.

a+

[Secco]

Envoyé par naphta

Bonjour,
Le tuning d'une nouvelle base avec plus de 10 utilisateurs en réseau peut durer jusqu'à un an.

Voilà de quoi me rassurer...
Je vais m'intéresser fortement au mode lecture seule je pense, car j'ignore complètement ça, mais y'a du boulot en effet !

[Pierre Fauconnier]

Bonjour

Envoyé par naphta

...

Le passage à SQL ne rend pas la base plus rapide au contraire....

Pour ma part, j'ai migré une appli "tout access" en SQL Server... Que du bonheur!

Suite à l'utilisation des déclencheurs et des procédures/fonctions stockées, on a pu alléger considérablement la charge réseau. Au final, une appli plus rapide et pas mal de boulot délégué au serveur.

Autre point: Formulaires ou états avec les fonctions de domaine. Une fonction de domaine est à chaque coup une connexion vers la base de données. Personnellement, je préfère amener toutes les infos via la requête source du formulaire. Idem pour les listes déroulantes, j'amène les infos dans la requête source puis je vais rechercher les données des colonnes de la liste plutôt que d'utiliser des fonctions de domaine.

[micniv]

Bonjour, Pierre

Pour ma part, j'ai migré une appli "tout access" en SQL Server... Que du bonheur!

As-tu migré en projet ADP (comme le laisse supposer l'utisation des PS ou des déclencheurs) ou bien es-tu resté en frontal .MDB avec des tables Sqlserver lièes (et dans ce cas, est-ce possible de se servir de procédures stockées ?) ?

Si, comme je le pressens , tu as migré en ADP, pourrais tu nous donner la volumètrie : nombre de tables, de formulaires et d'états et ton chiffrage du temps nécessaire à migrer en ACP (bien sûr chaque projet est différent et ... chaque développeur aussi)

Merci,

[Kloun]

Bonjour,

J'utilise Access sur une base SQL Server.
Mais je n'utilise pas de table liée.
Quand j'ai besoin de données pour un formulaire liste (consultation), je crée une requète SQL direct à la volée.
Quand j'ai besoin de données pour un formulaire unique (création/modification), je vais chercher les données qu'il me faut via un (ou des) recordset et j'alimente mon formulaire (j'utilise les tag des champs). Pour la sauvegarde, je crée mon SQL (Insert ou update) à la volée.
Dans quelques rares cas, je récupère les données dont j'ai besoin dans un recordset pour alimenter une table locale sur laquelle je fais mes traitements.

- Performance au top.
- Pas de problème de volumêtrie
- Utilisation réseau minimale

Que du bonheur.