Discussion :

[dvdbly]

Bonjour à tous,

Avant de poster dans "IHM", j'ai longuement douté... mais je me lance finalement.

Dans mon application, je rédige des devis.
Pour ce faire, il y a un formulaire "entête" du devis, avec un sous-formulaire listant les lignes du devis, en visu seule, et un formulaire "ligne de devis" pour la saisie d'une ligne.

Dans le formulaire "entête", j'ai disposé deux boutons permettant d'ouvrir le formulaire "ligne de devis" dans deux modes différents : AJOUT ou INSERT.
AJOUT ajoute la ligne en fin de devis, alors qu'INSERT insère la ligne au-dessus de la ligne en cours (inutile de dire que mes lignes sont numérotées et triées sur ce numéro).

L'ajout se passe sans problème, et l'insertion également, d'ailleurs, sauf dans un contexte bien particulier que voici.

Dans le formulaire "ligne de devis", un petit moteur constitué de cases à cocher, d'une zone de saisie des critères et d'un bouton d'exécution, permet d'effectuer des recherches multi-critères dans le catalogue choisi.
Une fois le bouton cliqué, les listes de choix de l'article sont alimentées à l'aide d'une requête composée à la volée après décomposition lexicale du contenu de la zone de saisie des critères, en fonction des cases cochées (certaines indiquant sur quels champs effectuer le recherche, d'autres précisant les opérateurs à utiliser entre les champs et entre les critères ainsi que le type de recherche, commençant par ou contenant).

Depuis peu (je dirais depuis que j'ai fractionné la base, mais sans certitude), l'utilisation de ce moteur de recherche - en mode insertion - provoque une erreur au moment où je tente d'enregistrer mon formulaire. Il s'agit de l'erreur 3188 "Impossible de mettre à jour; actuellement verrouillé(e) par une autre session sur cette machine.
Pour compléter cette description, il faut que j'indique que l'insertion se traduit par une requête qui sélectionne toutes les lignes du devis dont le numéro est supérieur ou égal à celui de la ligne en cours, et pour chacune d'elles, incrémente ce numéro.

Cette erreur apparaît depuis que j'ai mis le formulaire en Verrouillage = Enr modifié.
Auparavant, c'était l'erreur 3197, conflit d'écriture, qui se produisait.
Laquelle est réputée être réglée par Verrouillage = Enr modifié. De fait, cela fonctionne bien puisqu'elle ne se produit plus, mais que la 3188 s'y substitue ne me convient de très modérément !

Quelqu'un (entre)verrait-il une solution à mon calvaire ?

[Tofalu]

De ce que je comprends (vos explications sont claires mais le problème complexe donc je suis peut être à côté), vous essayez au final de changer une ligne qui est actuellement vérouillée par le sous-formulaire.

Avez vous essayé un appel à la méthode Refresh de ce sous formulaire depuis le formulaire d'insertion ?

Cela donnerait un truc du genre

Forms("NomDuFormulaireEntetedeDevis").(Nomducadrecontenantlesousformulaire).Form.Refresh

[dvdbly]

Bonjour Christophe,

Merci pour cette réponse !

De ce que je comprends (vos explications sont claires mais le problème complexe donc je suis peut être à côté), vous essayez au final de changer une ligne qui est actuellement vérouillée par le sous-formulaire.

Merci pour l'appréciation. Et oui, votre interprétation me semble bien correspondre de ce je comprends moi-même de mon problème.

Avez vous essayé un appel à la méthode Refresh de ce sous formulaire depuis le formulaire d'insertion ?

Cela donnerait un truc du genre

Forms("NomDuFormulaireEntetedeDevis").(Nomducadrecontenantlesousformulaire).Form.Refresh

Maintenant oui :

Code :

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

1
2
3
4
5
        ' Décalage des lignes suivantes, si l'on est en train d'insérer une ligne.
        If mode_entree_devis_detail = "INSERT" Then
            Forms("frm_Devis").[sfrm_Devis_detail].Form.Refresh ' 20130925
            Decaler_lignes (num_ligne_courante)
        End If

J'ai inséré le Refresh juste avant de décaler les lignes, c'est-à-dire juste avant d'accéder en écriture aux enregistrements litigieux...

D'ailleurs, je remets ici la procédure de décalage, in extenso, avec mention de l'endroit où le débogueur coince :

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
30
31
32
33
Private Sub Decaler_lignes(num_ligne_depart As Integer)
' Décale de 1 le numéro de toutes les lignes dont le numéro est sup. ou égal
'   à num_ligne_depart.
 
    Dim db As DAO.Database
    Dim rs As DAO.Recordset
    Dim UID_parent As String
 
    UID_parent = Me.UID_devis
 
    ' Initialise la base, puis le recordset.
    Set db = Application.CurrentDb()
    ' Sélectionne les lignes du devis en cours dont le numéro est supérieur ou égal au paramètre.
    Set rs = db.OpenRecordset("SELECT * FROM [tbl_Devis_detail] WHERE [UID_devis] = '" & UID_parent & "'" & _
            " AND [INT_Num_ligne] >= " & num_ligne_depart & " ORDER BY " & "[INT_Num_ligne] ASC")
 
    ' Parcours le recordset.
    Do Until rs.EOF
        ' Passe en mode modification.
>>>   rs.Edit <<<<<<<<<<<<<<<<<<<<<<<<<<< SANS SURPRISE, ÇA COINCE ICI !!
        ' Modifie le champ : incrémente le numéro de ligne.
        rs("INT_Num_ligne") = rs("INT_Num_ligne") + 1
        ' Met à jour l'enregistrement
        rs.Update
        ' Passe à l'enregistrement suivant.
        rs.MoveNext
    Loop
 
    ' Libère les objets.
    rs.Close: Set rs = Nothing
    db.Close: Set db = Nothing
 
End Sub

Malheureusement, cela ne règle pas le problème !
Ai-je appliqué correctement votre idée ?

[Tofalu]

Et dans le mode de verrouillage du sous-formulaire, vous avez quoi ?

[dvdbly]

Et dans le mode de verrouillage du sous-formulaire, vous avez quoi ?

Dans l'objet source (frm_Devis_detail) : "Aucun".

En outre :
Type Recordset = "Feuille de réponse dynamique".
Source = "req_Liste_Devis_detail" (une requête donc).
Modif autorisée = "Non"
Pas de filtre, pas de tri.
Entrée données = "Non"

Enfin :
Affichage par défaut = "Formulaires continus" (c'est la liste des lignes du devis).

Et dans le conteneur ("sfrm_Devis_detail"), j'ai une liaison père-fils entre l'entête et les lignes.


Merci de réfléchir à ce problème qui m'empoisonne la vie depuis quelques jours.

[Tofalu]

Juste pour avancer un peu dans la recherche, essayez :

Type Recordset = "Feuille de réponse dynamique" =>
Type Recordset = "Instannné"

De cette manière, il n'y aura plus de verrou dans le sous-formulaire puisque non modifiable.

Si ça ne résoud pas le problème c'est que l'on est sur la mauvaise voie.

[dvdbly]

Bonjour,

Malheureusement, l'erreur se produit toujours.
Ce que je ne comprends pas, c'est qu'elle n'apparaisse que si j'exécute une requête pour changer le contenu de mes listes de choix, et pas sinon !

[...]essayez :

Type Recordset = "Feuille de réponse dynamique" =>
Type Recordset = "Instantané"
[...]

[dvdbly]

Ce que je ne comprends pas non plus, c'est que dans ma ligne de devis, s'il y a effectivement le moteur de recherche qui compose la requête alimentant la liste de choix en changeant le .Rowsource :

Code :

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

1
2
    Me.Reference_article.RowSource = SQL_Reference
    Me.Reference_article.Requery ' Retirer le .Requery ne change apparemment rien au verrouillage.

avant même que l'utilisateur ne puisse utiliser le moteur, il doit choisir un catalogue d'articles, ce qui utilise déjà une requête et change le .Rowsource :

Code :

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

1
2
3
4
5
6
7
With Me.Reference_article
                .RowSource = "req_Catalogue_code"
                .ColumnHeads = True
                .ColumnCount = 5
                .ColumnWidths = "4cm;2cm;8cm;2cm;2cm"
                .ListWidth = 10204 ' 18cm
End With

et que cette première requête ne provoque pas de blocage des enregistrements, puisque si j'insère un article directement depuis la première liste de choix, sans utiliser le moteur de recherche, alors je n'ai pas de problème !

Petit récap de la chronologie :
Dans devis, clic sur bouton Insérer
-> ouverture formulaire "Ligne de devis", sans catalogue
-> sélection d'un catalogue -> actualisation du .Rowsource
|----> si sélection d'article depuis ce premier .Rowsource alors pas de problème ;
+----> si utilisation du moteur de recherche, alors ré-actualisation du .Rowsource et si sélection depuis ce second .Rowsource, alors message d'erreur à l'enregistrement du record dû au verrouillage.

Bizarre, bizarre, vous avez dit bizarre ? Comme c'est bizarre !

[dvdbly]

Christophe,

Ne cherchez plus, j'ai trouvé après moult recherches et tests.

La cause du problème est identifiée par "Raymond Access MVP" dans les posts suivants :
http://microsoft.public.fr.access.na...lit-d-ecriture
Le problème provient du fait que le code VBA et le formulaire travaillent en même temps sur les mêmes enregistrements. D'où je conclus que le moteur VBA dispose, et finalement c'est logique, de son propre verrou.

Dans ces posts, il donne également l'élément de solution le plus important, à savoir sauvegarder l'enregistrement en cours, ce qui de toute évidence libère le verrou VBA, avant de travailler avec le DAO.Recordset.

Dans mon cas, il s'agit d'insérer une ligne numéro n et de décaler toutes les lignes dont le numéro est >= n. Mais comme je suis obligé d'enregistrer ma nouvelle ligne n en cours d'insertion, avant de procéder au décalage, pour éviter de doublonner la ligne n+1 et de ne plus avoir de ligne n, je procède de la façon suivante :

a) je stocke dans une variable l'ID de la ligne n que je suis en train d'insérer ;
b) comme prescrit, je sauve la ligne n, ce qui fait que j'ai maintenant 2 lignes portant le numéro n ;
c) j'appelle la fonction de décalage en lui passant l'ID de la ligne en cours d'insertion ;
d) le décalage ne se fait plus sur les lignes >= n, mais sur les lignes >= n AND NOT UID = UID_de_la_ligne_en_cours_d_insertion.

Si je ne procédais pas de la sorte, j'aurais :

a) enregistrement de la ligne n en cours d'insertion, ce qui fait 2 lignes portant le numéro n ;
b) décalage des lignes >= n, d'où 2 lignes portant le numéro n+1 et plus aucune ligne avec le numéro n.

N.B. : ce nouveau fonctionnement est d'ailleurs nettement plus robuste puisque je suis maintenant sûr de ne jamais renuméroter la ligne insérée, ce qui n'était pas le cas avant.

La solution étant trouvée et d'après mes tests opérationnelle, je clos la discussion.
Merci Christophe de m'avoir aiguillé.