Discussion :

[Archikool]

Bonjour,

Je sais que ce sujet a dû être traité quelque part sur le forum, mais je cherche sans succès, peut-être que je n'écris pas les bons mots. Quelqu'un pourrait-il me rediriger sur le lien qui répondrait au problème suivant svp?

Lorsqu'un utilisateur tente d'ajouter un fichier dans la base via le champ pièces-jointes d'un formulaire, il arrive à l'occasion que l'ajout soit impossible. Access dit que le champ est verrouillé, mais ce n'est pas le cas dans les propriétés. C'est un problème aléatoire et s'il y a une solution pour le contourner, j'aimerais bien la connaître.

Merci à l'avance.

[argyronet]

Bonjour,

Comment procèdes-tu pour ajouter les dites pièces-jointes ?

Est-ce qu'au moment de l'ajout, seul ce champ est-il verrouillé ou bien le comportement est le même lorsque qu'un tiers tente de modifier une valeur de n'importe quel autre champ d'un enregistrement ouvert et en cours d'écriture par un autre ?

Argy

[Archikool]

Salut Argy,

Le champ PJ n'est pas verrouillé dans ses propriétés et le problème ne se présente pas avec d'autres champs. Ça arrive seulement avec PJ est c'est aléatoire. Si un utilisateur me passe la remarque qu'il tente l'ajout d'un fichier et que ça dit que le champ est verrouillé, donc ajout de PJ impossible, je ferme mon module frontal et soudainement, plus de verrouillage...Pourtant, mon frontal n'a rien à voir avec le sien non? On dirait que le problème vient de mon frontal.

Il y a un rafraîchissement de l'écran sur TimerInterval, est-ce qu'il pourrait à l'origine du problème?

Merci à l'avance pour ton attention.

[argyronet]

Il y a un rafraîchissement de l'écran sur TimerInterval, est-ce qu'il pourrait à l'origine du problème?

Quel code est utilisé ici ?

Explications :

Humm, disons que par défaut, les champs de type pièce jointe utilisent le verrouillage pessimiste même si l’option de verrouillage par défaut est définie à Aucun...

Si la propriété de Verrouillage (d’enregistrement) est définie sur Enr Modifié, la page d’enregistrement est verrouillée dès qu’un utilisateur commence à modifier n’importe quel champ de l’enregistrement et pas forcément la pièce jointe ; cette page restera verrouillée jusqu'à ce qu'il passe à un autre enregistrement car cet enregistrement n'est modifiables que par un seul utilisateur à la fois.

Ce que je te propose, c'est d'écrire une fonction qui permettrait soit :

• par un message issu d'un MsgBox() personnalisé ;
• soit par une mention dans un contrôle Label le fait que l'enregistrement est libre d'accès où non ;
• soit par affectation de la propriété Enabled d'un bouton "Modifier" sur ton formulaire (tous les champs ayant par défaut la propriété Locked à True en consultation).

Pour ce faire, ta fonction pourrait par exemple tenter de modifier un champ texte bidon (que tu as ajouté exprès dans la table) avec une valeur au hasard (le LOGIN de l'utilisateur et la date par exemple).
Si la fonction peut modifier, alors l'enregistrement est disponible et la pièce jointe pourra être ajoutée.
La page est alors verrouillée jusqu'au prochain Requery ou au Goto Next/Previous.

Argy

[Invité]

Lorsqu'un utilisateur tente d'ajouter un fichier dans la base via le champ pièces-jointes d'un formulaire, il arrive à l'occasion que l'ajout soit impossible. Access dit que le champ est verrouillé, mais ce n'est pas le cas dans les propriétés. C'est un problème aléatoire et s'il y a une solution pour le contourner, j'aimerais bien la connaître.

Bonjour.
Tu dis il arrive!

Donc c'est possible mais il arrive que ça marche pas!

As tu analysé dans quel condition?

Ta base est multi utilisateurs?
Bien que les enregistrements ne soient pas verrouillés y a t-il plusieurs utiliser sur la base de données?

Si l'administrateur (propriétaire de la base {créateur}) a ouvert la base de données il est exclusif!

Il n'a même pas besoin d'ouvrir une table toute la base est verrouillé!

Analyses le ou les cas de figure. L'informatique est logique pas intelligente les causes produisent toujours les mêmes effets. Ça fonctionne ou pas la fonction clignotant j'y crois pas!

Au pire si tu penses que le timer est en cause inhibe le pendant la mise à jour,sauf si tu as mis des doevent dans ta méthode de mise à jour il ne devrait pas ce déclenché vba n'est pas multi taches!

[Archikool]

Salut rdurupt et merci d'avoir réagit à mon questionnement.

Oui, la base est multi-utilisateurs.

Il arrive...oui en effet, il arrive. Je sais que l'informatique n'est pas intelligent. Le "il arrive" fait plutôt référence à lorsqu'un utilisateur (ou moi-même) tente d'ajouter un fichier au champ, c'est tout. Je me suis probablement mal exprimée.

Sur l'événement TimerInterval du formulaire concerné, c'est seulement un refresh, rien de complexe. Je ne pense pas finalement qu'il soit l'origine du problème. J'ai plutôt le sentiment que c'est réellement le fait que je demeure sur un enregistrement assez longuement pendant la modification qui provoque le problème de verrouillage, et ça aurait franchement du sens en y repensant bien, parce que lorsque je quitte l'application, le champ des PJ n'est plus verrouillé. Cette réflexion fait suite à la lecture du dernier commentaire de Argy.

Alors Argy, je pense bien que je vais tenter une de tes solutions prochainement. Je me mets une petite note pour revenir faire un "update" de la situation sur le forum quand j'aurai une minute pour tester.

Merci beaucoup à vous deux pour votre temps et je redonne des nouvelles sans faute.

[Invité]

Bonjour,
Personnellement je mets toujours un booléen pour prévenir qu'un utilisateur manipule la bas de données.
Ainsi il ne sont pas concernés par ce genre de problème. Bien sur l'enregistrement disparait pendant un temps données mais je m'affranchi du désagrément!

[Archikool]

Bonjour,
Personnellement je mets toujours un booléen pour prévenir qu'un utilisateur manipule la bas de données.
Ainsi il ne sont pas concernés par ce genre de problème. Bien sur l'enregistrement disparait pendant un temps données mais je m'affranchi du désagrément!

Salut rdurupt,

T'as raison, je n'en doute pas. En fait, toi et Argy êtes très certainement beaucoup plus expérimentés que moi

Je vais me concentrer à appliquer la solution qui convient le mieux à mon application et je reviens avec le résultat.

À plus !

[Invité]

Tu as très vraisemblablement raison , mais si les débuts de Argy ont été aussi laborieux que les miens bonjour.

Quand j'étais encore gamin, j'ai travaillé pour un grand enseigne cher à Iggy pop.

Je devais faire un moteur de recherche sur un base Oracle.

Le teste sont passés comme une lettre à la poste. Mais quand on a chargé lesn700 000 000 000 ?????? Article le chef de projet qui voulait quand même, rien que pour rigoler, laisser la recherche aller à son terme, a killer le processus au bout 1 semaine!

[Archikool]

Bon alors voilà, d'abord bonjour Argy et rdurupt!

En m'inspirant de ce que Argy a écrit ici, voici ce que j'ai fait :

J'ai une table comprenant tous les comptes des utilisateurs de l'application. J'ai donc ajouté un champ "fantôme" pour effectuer une validation à un endroit bien précis dans la base, soit l'endroit où le verrouillage du champs des pièces-jointes survient sans que ce ne soit souhaité. Sur activation du formulaire, une petite requête ajoute le numéro unique du dossier consulté dans le champ "fantôme". À chaque changement d'enregistrement, le numéro de dossier est remplacé par le nouveau (rqt mise à jour). Lorsque l'utilisateur sort de ce formulaire, le champ "fantôme" est vidé à l'aide d'une autre requête. Finalement, une dernière requête a été créée : celle-ci vérifie si le numéro de dossier dans lequel un utilisateur se trouve est également consulté par un autre utilisateur au même moment.

Je dois d'abord mentionner que je suis la seule à avoir l'autorisation d'écrire dans tous les champs. Pour les autres utilisateurs, les autorisations dépendent du statut qui leur a été attribué dans l'application. Pour cette raison, j'ai placé la procédure seulement pour le champ PJ, car dans ce volet de mon application, il est le seul champ accessible à tous sans exception.

Donc, au moment où un utilisateur tente d'ajouter une pièce-jointe (sur réception focus), voici ce qui se produit :

1) On vérifie si on trouve le même numéro de dossier consulté par un autre utilisateur. Si oui, alors...
2) Le focus est passé à un autre champ, le verrouillage du champ pièces-jointes est appliqué (locked = True) et un message affiche que le dossier est en cours d'utilisation par (nom de l'autre utilisateur) et suggère d'y revenir plus tard.

Voilà, j'ai opté pour le "très simple" pour moi. Si vous avez mieux, je suis ouverte, mais pour le moment, cette petite solution inspirée de Argy semble faire l'action souhaitée.

Bonne journée à vous deux et merci encore de votre temps!

Au plaisir.

[Archikool]

Oh...et en passant les mecs, j'ai hâte d'avoir autant d'expérience que vous! Par chance, je suis débrouillarde, c'est toujours bien un début!

En passant, le fait que je sois à la fois l'administrateur mais également un utilisateur de l'application moi-même a motivé le choix de la solution quant au verrouillage du fameux champ des pièces-jointes. Je ne pouvais me permettre de tout verrouiller, parce que je suis celle qui utilise le plus l'application dans mon travail de tous les jours. J'ai un travail à deux volets si on veut : je suis à l'emploi du service labo et je développe en même temps des solutions pour la gestion de certaines données. Ça ne porte pas de nom précis comme poste à part agente de bureau, mais je prends plaisir à trouver des solutions .

J'ai une courte formation VBA, j'apprends vite et j'ai la chance d'avoir un collègue technicien informatique qui a bien voulu m'aider à comprendre mes propres erreurs et me corriger. Également, il ne faut pas que j'oublie de remercier tous ceux et celles qui participent à ce site web que je trouve extraordinaire, il a fait partie de mon apprentissage au fil du temps.

J'espère pouvoir me diriger vers C# dans un avenir rapproché. Qui sait ce que l'avenir me réserve!

À plus!

[Invité]

Bonsoir,
Tu as raison de choisir C# à Vb.net car la tentation est grande de travailler de la même façon.

Un autre langage va t'obliger à revoir ton mode de pensées!

[Archikool]

Ouais, je sais...j'aime les défis