Discussion :

[marot_r]

Bonjour à tous.

Voici un truc étrange qui m'est arrivé avec le code ci-dessous qui est un MAJ/Ajout en lieu et place d'une requête d'ajout et d'une requête de modification.

Un MaxLocksPerFile est apparu en plein milieu de mon traitement.

Ce code ne comporte aucune extravagance et n'est pas utilisé dans une transaction.
Et je fais mes test seul sur mon PC en local, donc pas de blocage multi-utilisateur.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
    Dim db As DAO.Database: Set db = CurrentDb
    Dim rDonnees As DAO.Recordset: Set rDonnees = db.OpenRecordset("reqBottin_Remplir", dbOpenSnapshot)
    Dim rBottin As DAO.Recordset: Set rBottin = db.OpenRecordset("tblBottin_Base", dbOpenDynaset)
    
    Dim f As DAO.Field
    
    Do While Not rDonnees.EOF
        iProgression = mdlProgression.GererProgression(prmFrmProgression, iProgression, 1) 'Affiche la barre de progression.
        
        Call rBottin.FindFirst("[NoMatricule]=" & rDonnees![NoMatricule])
        
        If Not rBottin.NoMatch Then
                rBottin.Edit
            Else
                rBottin.AddNew
        End If
        
        For Each f In rDonnees.Fields
            rBottin.Fields(f.Name) = f
        Next f
        
        rBottin.Update: DoEvents 'Le DoEvents force Access à libérer l'enregistrement
        
        rDonnees.MoveNext
    Loop
    
    rBottin.Close: Set rBottin = Nothing
    rDonnees.Close: Set rDonnees = Nothing
    db.Close: Set db = Nothing

Il a fallu que j'ajoute un DoEventsaprès le Update car sinon, en gros à la moitié du traitement Access afficher que j'avais atteint le MaxLocksPerFile que je devais changer cette variables.
C'est d'autant plus étonnant que mon sous-programme d'affichage de barre de progression comporte lui aussi un DoEventsqu'il est appelé à chaque enregistrement.

En espérant avoir aider à préserver quelques cheveux :-).

P.S. Et encore plus étrange, j'ai refait un test en enlevant le DoEvents et je n'ai plus de message d'erreur.


A+

[Jean-Philippe André]

SAlut,

c'est pas tant du a une transaction qu'a un nombre maximum atteint de lock :/
https://support.microsoft.com/fr-fr/kb/815281

[marot_r]

Merci jpcheck de ta contribution.

C'est surprenant d'avoir un problème de Lock avec un update à chaque enregistrement et qu'en plus cela disparaisse après.

A+

[marot_r]

Encore plus étrange, il est de retour ET avec le DoEvents.

J'ai résolu le problème en déplaçant l'ouverture et la fermeture de la table mise à jour (rBottin) dans la boucle de parcours des données.

Évidemment c'est plus lent .

A+

[Papy Turbo]

Bonjour,

Oui, les locks sont un monde + étrange que les pokemons, et bien moins faciles à contrôler.
Ma suggestion serait surtout de remplacer le tout par 2 requêtes action : 1 'mise à jour' qui recopie toutes les valeurs, pour chaque champ de tbl_Bottin_Base, à partir de ceux de req_Bottin_Remplir, et 1 'ajout' qui ajoute tous les enregistrements qui n'y existent pas encore.

Ça devrait être beaucoup plus rapide et, a priori, pas de problème de locks.

[marot_r]

Merci Papy Turbo.

Je suis d'accord avec toi pour la partie vitesse mais mon client passe son temps (j'exagère un peu mais pas trop) à changer ces spec. ce qui a un impact assez régulièrement sur mes tables.

Mon code VBA est capable de gérer cette variation de structure sans modification. Si je passe par des requêtes il va falloir que je pense à les modifier aussi.

Il se peut néanmoins que j'en vienne là car en réseau mon appli est parfois très lente ... pas ma faute ... mon réseau a de GROSSES variations de vitesse.
A+

[Papy Turbo]

Bonjour, René,

Est-ce que tu as pensé à faire une requête qui s'adapte aux nouveaux champs : sur le même principe que ta routine qui copie le contenu de chaque champ, tu crées un string contenant tous les noms des champs à l'intérieur d'une requête action. Tu n'as plus ensuite qu'à exécuter cette requête dans ton code.

Tu conserveras ainsi la souplesse de ta solution actuelle, quels que soient les nouveaux champs de ces tables, et la rapidité de la requête.

Bonne chance,

Etienne

[marot_r]

Bonjour Étienne.

En effet, bonne idée, si je suis amené à faire des requêtes, je procéderai comme cela.

Habituellement j'évite le SQL dans le code mais là cela se justifie pleinement.

A+