Discussion :

[random]

je veux mettre à jour par dao de grandes quantités de données.
j'ai en entrée une requête sélection que je parcours avec des movenext.
si l'enregistrement remplit les conditions requises j'ai un update du record.
j'obtiens le message d'erreur 3052 maxlocksperfile insuffisant
j'ai donc mis dans la base des registres cette clef à sa valeur maximale(maxint)
l'erreur persiste...
je suis obligé de découper mon traitement par lot pour contourner ce problème, cette méthode nuit gravement aux performances.
est il possible de contourner ce problème ? apparemment il faudrait créer une propriété usetransaction associée à une requête sélection.
mais je ne trouve pas comment faire.
merci d'avance.

[marot_r]

Je ne suis pas certain que cela peut t'aider mais les transaction se gère ainsi dans du code DAO.

Code :

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

1
2
3
4
5
6
7
8
9
 
dim w as workspace:set w=DBEngine.Workspaces(0)
w.beginTrans()
.
.
.
w.CommitTrans() ou w.Rollback selon le cas
 
set w=nothing

A+

[random]

merci Marot mais il ne s'agit pas de gérer une transaction
mais apparemment d'après les pistes déjà trouvées d'ajouter une propriété
à une requête sélection
en fait quand on a une requête mise à jour on peut inhiber la fonction transaction par clic droit propriétés puis propriété transaction à non
cette possibilité n'est pas ouverte pour les requêtes sélections mais
si j'ai bien compris pour règler mon problème il faudrait l'ajouter à ma requête
et là je sèche

[=JBO=]

Bonjour,

Je te suggère 2 pistes:

(1) Verrouiller le Recordset.
La procédure prend alors le contrôle exclusif des données traitées ce qui empêche la "prolifération" des verrous sur les pages.
Conséquences:
* les données ne seront plus accessibles simultanément par d'autres utilisateurs.
* je pense que ça devrait considérablement accélérer le traitement (à confirmer !?).

Code DAO:

Code :

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

Set RS = CurrentDb.OpenRecordset(SQL, dbOpenDynaset, dbDenyRead + dbDenyWrite)

(2) Paramètre de base de registre: PagesLockedToTableLock
Avec ce paramètre le moteur de bases de données JET est chargé d'adapter la stratégie de verrouillage des données. En fonction du nombre de verrous posés, il peut "décider" de basculer d'un mode verrouillage par pages en un mode verrouillage exclusif des tables concernées.

Cf. le paragraphe "Lock promotion" dans http://support.microsoft.com/default...b;en-us;275561

Ce paramètre est aussi accessible directement avec ADO via la propriété [Jet OLEDB:Page Locks to Table Lock] de l'objet Connection.

[random]

ni le dbdenywrite ni le dbdenyread ni leur addition n'ont d'effet
j'ai déjà réglé maxlocksperfile au maximum admissible

[LedZeppII]

Bonjour,
Lorsque nous sommes passés sous Access 2000 il y a 4 ou 5 ans, j'ai eu ce problème.
Le seul moyen pour le contourner a été de décocher l'option
'Open databases using record-level locking' dans l'onglet 'Avancé'
(Ouvrir avec vérrouillage au niveau enregistrement, en français ??)

Slts

[=JBO=]

Lorsque nous sommes passés sous Access 2000 il y a 4 ou 5 ans, j'ai eu ce problème.
Le seul moyen pour le contourner a été de décocher l'option
'Open databases using record-level locking' dans l'onglet 'Avancé'
(Ouvrir avec vérrouillage au niveau enregistrement, en français ??)

En français, dans les options d'Access 2000 (et suivants ?), Onglet [Avancé] décocher la case [Ouvrir avec enregistrements verrouillés].
Puis relancer Access (dans le but de recharger Jet).

Je confirme cette piste, sans programmation:

Le verrouillage par enregistrement est arrivé avec Jet 4.0 / Access 2000.

Si le moteur Jet applique un verrouillage au niveau enregistrement et si les enregistrements sont de petites tailles alors tu peux "économiser" des verrous en appliquant un verrouillage par page.

Le verrouillage au niveau de la page peut améliorer la situation à la condition qu'une page contienne plusieurs enregistrements.
Supposons que la taille d'un enregistrement soit de 500 octets, pour une taille de page de 4Ko: il y a 8 enregistrements/page.
Le verrouillage par page posera 8 fois moins de verrous qu'un verrouillage par enregistrement.

Attention: l'accès concurrent aux données peut s'en trouver fortement dégradé (applications multi-utilisateurs)

Mais le problème du nombre limité de verrous existe toujours, sur les très grandes sources de données.

Quelques explications:

Ce problème semble bien être une limitation "by design" du moteur de bases de données Jet 4.0.
Effectivement, le paramètre MaxLocksPerFile permet de repousser la limite du nombre de verrous, mais pas à l'infini.

Alors comment faire pour gérer une telle situation ?
Lorsque le maximum de verrous est atteint, il faut "libérer" le recordset (et donc les verrous) et puis ensuite reprendre le traitement là où on l'avait "suspendu". Il n'y a pas de contournement.

Apparemment, Jet 4.0 met en oeuvre une telle démarche incrémentale dans le cadre de "grosse" requête UPDATE (transactionnée seulement ?).
Dans cette configuration, le paramètre MaxLocksPerFile est utilisé par Jet pour décider à quel moment entériner les modifications déjà faites, libérer les verrous et puis reprendre le traitement, sans jamais dépasser cette limite.

En revanche, dans le cas d'une programmation directe des Recordsets via VBA/DAO (comme c'est apparemment ton cas Random), le programmeur doit mettre en oeuvre cette démarche dans son code (comme tu nous l'a expliqué).

Dans mes recherches sur l'internet, j'ai lu un témoignage intéressant qui propose de travailler en 2 temps, via une table de travail.
(0) créer une table de travail (temporaire) et l'ouvrir en accès exclusif (donc un seul verrou).
(1) modifier la procédure VBA pour insérer dans la table de travail les données à modifier (toujours 1 seul verrou).
(2) effectuer la mise à jour vers la ou les tables de destination au moyen d'une requête UPDATE (laisser faire le mécanisme incrémental de Jet).

The MaxLocksPerFile setting allows the Microsoft Jet database engine to complete large transactions without exceeding a specified record lock limit. Instead of exceeding this limit, the Jet database engine splits a transaction into two or more parts; after one part has been committed, the Jet database engine frees the locks so that they can be reused. As a result, fewer locks are required to complete the transaction. This prevents a Novell Netware server, which limits the maximum record locks per connection to 10000, from crashing when that value is exceeded.

However, the Jet database engine does not split the transaction when it synchronizes two replicas. If the transaction cannot be completed within the limit specified in the MaxLocksPerFile setting unless it is split into parts, you receive the error 3052; the synchronization does not occur.

Une dernière piste, sans programmation:

Une autre piste pour faire des "économies":
Jet pose des verrous supplémentaires sur les indexs. On peut envisager de supprimer les indexs inutiles.

Et le paramètre PagesLockedToTableLock ?

Dans mes tests, sa modification n'a eu aucune incidence .

[random]

merci
merci à vous deux

LedZeppII
non seulement ta solution marche mais je muliplie mes perfs par un facteur 15

je n'aurais pas pu utiliser un update puisque les modifications d'un enregistrement dépendent d'un nombre inconnu d'autres enregistrements

[LedZeppII]

Merci à JBO pour les explications.
J'avoue n'avoir jamais compris le pourquoi de ma 'solution'.
A l'époque j'avais juste comparé les options avancées 97 et 2000 pour voir ce qui avait changé.

Autres remarques :
Je n'ai plus ce problème avec Access 2003 (j'ai deux PC; un en office 2000 et un en office 2003)
Chez moi je n'ai pas ce problème non plus avec XP et Access 2000.
Je ne l'ai eu qu'avec Access 2000 sous Windows 98, NT, et 2000.

A+