Discussion :

[dan664]

Bonjour,

J'ai une applic en 2 parties : un frontend ou applic utilisateur; une db qui contient les tables.

Les frontends se connectant à la db centrale rencontrent de gros problèmes de lenteur et parfois une impossibilité de sauver leurs modifs.

On m'assure que le réseau ne connaît pas de problème....
Pourtant, lorsque je recopie les 2 applics sur mon disque local, tout fonctionne parfaitement....

Quelqu'un a-t-il une idée ?

Merci d'avance pour votre aide,

Dan664

[yoyopi]

A la base access est une base mono utilisateur non?

[=JBO=]

A la base access est une base mono utilisateur non?

NON

ACCESS est un système de gestion de bases de données MULTI-UTILISATEUR

Pardonne moi yoyopi si je suis un peu vindicatif, mais c'est un sujet hyper rabâché sur ce forum.
D'autre part, ce serait bien que tous les participants au forum Access aient une idée claire sur les fonctionnalités "élémentaires" de ce SGBD.

Nous sommes nombreux à mettre en oeuvre des applications multi-utilisateur basées sur Access, sans rencontrer de Pb tant qu'on reste dans les limites du raisonnable (BD pas trop grosse, nombre limité d'utilisateurs simultanés...).

Pour en revenir au Pb de Dan664:

Est-ce que chaque PC utilisateur exécute son propre exemplaire de la bd application (alias frontend) ?
Ou bien est-ce le même fichier partagé par tous ?

As-tu fait le test, en configuration réseau, d'une utilisation par un seul utilisateur ? Les temps de réponse sont-ils déjà mauvais à ce stade ?

[dan664]

Bonjour,

Oui, tous les utilisateurs (ils ne sont que 4) utilisent leur frontend. Avec un seul utilisateur, il y a moins de pb.

J'ai déja réalisé des db semblables utilisées par un + gd nbre d'utilisateurs sans rencontrer le moindre pb mais ici.... Peut-être une subtilité dans les paramètres d'Access ??

[=JBO=]

Bonjour Dan664,

J'ai déja réalisé des db semblables utilisées par un + gd nbre d'utilisateurs sans rencontrer le moindre pb mais ici...

En ce qui concerne Access/Jet, tu peux t'intéresser à 2 pistes:
>> le verrouillage optimiste/pessimiste,
>> la granularité du verrouillage (par page ou par ligne)

Quel est le "comportement" de ton application vis à vis des accès concurrents.
Exemples:
>> si tous les utilisateurs lancent simultanément des requêtes qui modifient les mêmes données, il y a des risques de blocages ou de ralentissement.
>> si les utilisateurs font des mises à jour sur des sources de données issues d'une jointure 1-n avec un verrouillage pessimiste, alors les lignes du côté n de la jointure sont verrouillées ce qui empêche les mises à jour sur d'autres lignes côté 1 qui sont jointes avec ces mêmes lignes verrouillées coté n (suis-je bien clair ).

Peut-être une subtilité dans les paramètres d'Access ??

Ou une subtilité du réseau ? ou du système d'exploitation ?
Peux-tu préciser:
>> le type de réseau (Windows, Novell, autre...)
>> le système d'exploitation du serveur de fichiers où la BD est stockée.

[dan664]

Bonjour et désolé pour le temps de réponse (j'étais en congé;-)

Le réseau est un réseau fast ethernet 100Mb
L'OS du serveur est Win2003
L'OS des clients est Xp SP1.

Ou puis-je vérifier les param. de verrouillage et de granularité dont vous parlez ?

[=JBO=]

Bonjour dan664,

Ou puis-je vérifier les param. de verrouillage et de granularité dont vous parlez ?

Le type de verrouillage est spécifié pour chaque formulaire et requête Access à travers la propriété [Verrouillage] (RecordLocks en anglais).

Cette propriété est accessible dans la fenêtre des propriété,
>> dans l'onglet [Général] pour les requêtes Access,
>> dans l'onglet [Données] pour les formulaires,
>> dans l'onglet [Autres] pour les états.

Selon le contexte, pour la propriété [Verrouillage] les valeurs possibles sont:
>> [Aucun], verrouillage optimiste, appliqué après validation des modifications,
>> [Enr modifié], verrouillage pessimiste, appliqué dès que commence la modification d'un enregistrement,
>> [Général] ou [Tous les enregistrements], verrouillage de l'ensemble des enregistrements concernés (affichés/imprimés) interdisant toutes modifications aux autres utilisateurs.

La granularité du verrouillage (Page ou Enregistrement) est définie au niveau de la boîte de dialogue des Options d'Access.
Pour l'afficher, on exécute la commande [Options...] du menu [Outils].
Il faut sélectionner l'onglet [Avancé].
La granularité du verrouillage est contrôlé par la case à côcher [Ouvrir avec enregistrements verrouillés].
>> si cette case est cochée, alors le verrouillage n'est appliqué qu'à l'enregistrement modifié;
>> si cette case est décochée, alors le verrouillage est appliqué à la page qui contient l'enregistrement modifié; par conséquent, tous les enregistrements de la page sont verrouillés pendant la modification.

Si plusieurs instances d'Access (en fait, du moteur Jet) qui accèdent à la même base de données ont des options de verrouillage différentes, alors c'est la première instance qui ouvre la BD qui fixe la granularité du verrouillage pour toutes les instances.

Le verrouillage par enregistrement est disponible à partir d'Access 2000 / Jet 4.0 / DAO 3.6.

Les Options d'Access permettent aussi de définir le type de verrouillage par défaut pour les nouvelles requêtes ou les nouveaux formulaires.

[dan664]

J'ai vérifié ces paramètres sur tous les postes clients et tout était réglé en fonction de l'accès optimiste >> le problème se situe ailleurs....

[micniv]

Vérifier aussi les performances du réseau lui-meme :

Est-ce un domaine ? ou un workgroup , dans ce cas est ce que tous les PC sont dans le mem workgroup ?

Quand est-est il du parametrage du fire-wall XP (XP SP2) sur chacun des postes? les droits des utilisateurs ? (j'ai personnellemnt vecu des droits et des perfs bizarres sur un reseau de 3 XP dont un en wi-fi).

Bref, il ne faut rien négliger quand les perf ne sont pas au rendes-vous !
Slt

[Arkham46]

slt,

parfois ça se résoud comme ça :
1 - créer une table bidon sur le serveur
2 - lier cette table sur le frontend
3 - ouvrir cette table lié depuis le frontend via un recordset à l'ouverture de la base
4 - ne pas refermer le recordset

c'est un peu stupide mais le fait de forcer access à garder une connection ouverte évite qu'il ne perde et recrée la connection au serveur continuellement...

j'ai déjà vu des grosses améliorations des perfs avec cette "technique"