Discussion :

[harpyopsis]

Bonsoir !

Quelqu'un sait-il quel seuil doit être dépassé pour que se déclenche l'erreur 3052 : "Le nombre de verrous disponibles pour le partage des fichiers est dépassé..." lors d'une synchro "SynchronizeDBsJRO LocalPath, SynchPath, SyncType, 2" ???

Est-ce la taille du fichier mdb, ou le nombre de Tables dans ce fichier, ou le nombre d'enregistrements dans les plus grosses Tables, ou le nombre total et le type de champs, ou la complexité des relations entre les Tables???

Ce fichier mdb pèse 127.000Ko, contient environ 45 Tables, dont la plus lourde possède 30.000 enregistrements.

Ce n'est pas énorme...

Je viens d'avoir cette erreur pour la première fois sur tous les postes en même temps après l'ajout quotidien de quelques nouvelles lignes. Il n'y avait eu aucune modification de structure des Tables depuis plusieurs semaines.

J'ai donc modifié MaxLockPerFile, via
- le registre (de 9500 à 15000)
- le code VBA (DAO.DBEngine.SetOption dbMaxLocksPerFile, 15000).

Sans effet.

J'ai décoché Options/Advanced/"Open Databases using record-level locking".

Sans effet non plus.

Vu la complexité de la synchronisation, il n'est pas envisageable de remplacer celle-ci par d'innombrables UPDATE queries.

Ma question essentielle est de savoir s'il serait utile de scinder ce fichier mdb en plusieurs fichiers plus petits ??? Avec l’inconvénient de perdre beaucoup d'intégrité référentielle, ce qui serait dommage.

Je pense naturellement à migrer définitivement cette base Access vers un autre format, et toutes les suggestions sont les bienvenues !

Merci !

[harpyopsis]

Bonsoir à tous...

Faute de trouver d'explication satisfaisante sur la cause précise de ce problème, je me suis résolu ce week-end à créer un nouveau fichier mdb tout frais, pour y importer l'ensemble des Tables + Relationships du mdb qui refusait de synchroniser en raison de ces >9500 "verrous", puis à recréer son petit set de replicas.

A peine dix minutes de travail, en fait. J'aurais bien-sûr du essayer cela plus tôt.

Succès immédiat !

La synchronisation est redevenue très rapide, alors qu'elle avait tendance à prendre plus d'une minute depuis plusieurs mois sur ce fichier qui a déjà deux ans d'âge avec plusieurs synch par jour.

J'en conclus -peut-être fort naïvement, qu'Access doit multiplier ses verrous dans les system et hidden files, qui conservent l'historique des synchronisations et des conflits. Au bout d'un temps assez long, ça peut déborder...

Brave Old Access....

Je ne marque pas ce fil comme résolu, si jamais quelqu'un pouvait apporter une explication plus détaillée du mécanisme MaxLocksPerFile...

Un très très grand merci à Laurent pour son excellente analyse !

phil

[Paraffine]

Bonsoir Harpyopsis,

J'ai rencontré le même problème, non pas avec une synchronisation, mais avec une mise à jour en masse dans une base Sqlserver, à partir de tables Access, ce qui m'avait surprise dans la mesure où je ne comprenais pas l'utilisation de verrous à l'enregistrement dans ce cas (il s'agissait d'ajouts en masse dans Sqlserver). Comme la modification que tu évoques via VBA a fonctionné pour moi, je n'ai pas cherché plus loin (c'est la méthode recommandée - plutôt qu'une modification dans la base de registre - dans la mesure où sa portée est limitée à la session).

La FAQ donne quelques lumières sur les verrous, ici, mais toujours dans le contexte des mises à jour via Recordset.

Cordialement,
Paraffine.

[harpyopsis]

Bonjour Paraffine !
Merci pour ce sympathique message !
En effet, les forums proposent quelques lumières sur les verrous en général, mais rarement en ce qui concerne les verrous sur opérations de synchronisation.
Faute d'autres explications, je penche pour un alourdissement excessif des system objects avec le temps.
Il suffit donc de reconstruire le fichier mdb et de recréer le set de réplicas. C'est bête!
J'avais autrefois un soft "Stellar Phoenix Access Repair" qui détectait et réparait assez bien d'erreurs dans les fichiers mdb, mais ce logiciel causait aussi beaucoup de pertes de Tables ou de Formulaires. Je l'ai abandonné.
Très bonne journée à toi !
phil