Discussion :

[Eruil]

Bonjour,
Je viens de reprendre une application développée par mon prédecesseur. Sur cette application on crée des fiches clients et fréquemment on revient sur ces fiches pour compléter leur dossier. En moyenne, entre dix et quinze personnes travaillent en même temps sur cette application. Il s'agit d'un formulaire contenant les infos du client contenant un sous-formulaire répertoriant les courriers qu'on lui a déjà envoyé

Cette application plante constamment (entre 5 et 10 fois par jour). Il semble qu'il y 'ai un problème de verrouillage des enregistrements. Le problème le plus fréquent est lorsque quelqu'un crée une nouvelle fiche client

Code :

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

1
2
3
On Error goto Err_Nouvelle_Fiche
DoCmd.GoToRecord , , acNewRec
On Error GoTo 0

l'erreur suivante est levée : code erreur 2105 Impossible d'atteindre l'enregistrement spécifié.

Les solutions que j'ai déjà tentées :
- Fractionner la base. J'ai disposé la base dorsale dans un dossier partagé et une copie de la base frontale est a disposition sur chaque poste
- Dans les propriétés du formulaire et de son sous formulaire j'ai positionné le champ verrouillage à Enr modifié et le champ Type RecordSet à Feuille rép.dyn.(MAJ globale)
- J'ai essayé de creer le nouvel enregistrement dans le code vb en DAO j'y arrive (il est bien inséré dans ma table) mais cependant je n'arrive pas, immédiatement après l'avoir crée, à me positionner par le code sur ce nouvel enregistrement dans mon formulaire

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
set oRsb = oDb.OpenRecordset(matable,dbOpenDynaset)
oRsb.addNew
oRsb.Fields("Id") = "toto"
ind = oRsb.Fields("Num").Value
oRsb.Update
 
' mode bidouillage on c'est le seul moyen que j'ai trouvé pour afficher mon enregistrement dans mon formulaire mais ça me semble hyper crad'
Dim crit as String
crit = "[Num_ligne] = " & ind
oRsb.FindNext crit
set temp = Me.Recordset
set Me.Recordset = oRsb
temp.close
set temp = nothing
'mode bidouillage off

Je vous remercie de toutes les pistes que vous pourrez me donner car cela fait plus d'une semaine que je patauge et que je cherche a régler ou contourner ce problème.

Merci d'avance

[Domi2]

Bonjour,

En premier lieu, vérifie également que dans les options des bases frontales, onglet "Avancé", le mode d'ouverture par défaut soit sur Mode partagé, le Verouillage par défaut sur Enregistrement modifié et qu'Ouvrir avec enregistrements verrouillés soit coché.

Cela éliminera déjà une possibilité.

Domi2

[Eruil]

En premier lieu, vérifie également que dans les options des bases frontales, onglet "Avancé", le mode d'ouverture par défaut soit sur Mode partagé, le Verouillage par défaut sur Enregistrement modifié et qu'Ouvrir avec enregistrements verrouillés soit coché.

Merci de ta réponse, ceci est déjà fait dans le code au démarrage de l'application :

Code :

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

1
2
3
4
Application.setOption "Default Open Mode for Databases", 0
Application.setOption "Default Record Locking", 2
Application.setOption "Use Row Level Locking", 1
Application.setOption "Number of Update Retries", 5

[Domi2]

Re,

J'imagine que la propriété ajout du formulaire est bien à oui ?

Domi2

[Eruil]

J'imagine que la propriété ajout du formulaire est bien à oui ?

Les propriétés du formulaire principal et de son sous-formulaire sont définies comme suit :

Modif autorisée : oui
Suppr autorisée : oui
Ajout autorisé : oui
Entrée données : non
Extraction des paramètres par défaut : oui

Merci de ton aide

[Domi2]

Re,

Sorry, mais pas beaucoup d'idée...

Un problème de relation ou d'index ?

As-tu essayé, sur une copie de ta base dorsale, de supprimer puis de rétablir les relations ?

Je n'y crois pas beaucoup, mais...

Domi2

[Eruil]

As-tu essayé, sur une copie de ta base dorsale, de supprimer puis de rétablir les relations ?

Non je n'ai pas encore essayé ceci. J'essaierais ce soir pour tester demain car je ne peux pas interrompre le travail de mes collègues en journée (surtout qu'ils commencent à me regarder bizarrement à cause de tous ces plantages )
Merci.

Si toi ou quelqu'un d'autre ont d'autres suggestions je suis près à (presque) tout tester.

[Eruil]

Est-ce que ce silence signifie que personne d'autre n'as d'idée ou alors qu'on m'a déjà oublié ? Je suis désolé d'avance de m'incruster comme ça ...

[Domi2]

Re,

Après un peu de réflexion

D'abord réimporter les objets des deux tables dans des bases vierges. Il s'agit peut-être d'un début de corruption

Je ne crois pas que cela apporte grand-chose pour la base dorsale, qui ne contient que des tables, mais je ne suis pas assez connaisseur pour pouvoir l'affirmer.

Une fois fait, compacter et réinstaller dans l'environnement de production.

Si cela ne donne rien, après, j'essaierais de procéder par élimination.

En travaillant sur une copie des tables, je commencerais par essayer de saisir de nouveaux enregistrements directement dans la table.

Puis de passer par un formulaire tout simple, d'abord en attaquant directement la table, puis en passant par la requête sous-jacente s'il en existe une... etc...

Désolé, mais je n'ai pas de meilleures idées

Domi2

[Eruil]

Cela vient de planter à nouveau ... Alors j'en ai profité pour leur soumettre une nouvelle version dans laquelle j'ai viré le sous formulaire (c'était une relation 1:1 alors je l'ai inclus dans le formulaire principal).

Du coup : une seule table, un seul formulaire et 0 relation ..... Mais ça renvoi encore des erreurs à foison : "Impossible d'atteindre l'enregistrement spécifié" en cas de création d'une nouvelle fiche et "impossible de lire l'enregistrement actuellement verrouillé par un autre utilisateur" en cas de recherche d'une fiche existante.

Au bout d'1 semaine de débuggage on peut dire que je patine et que je désespère

[Domi2]

Re,

Cela vient de planter à nouveau ... Alors j'en ai profité pour leur soumettre une nouvelle version dans laquelle j'ai viré le sous formulaire (c'était une relation 1:1 alors je l'ai inclus dans le formulaire principal).

Une relation 1:1 pour un suivi de courrier ?

Ca ne provient certainement pas de là, mais il me semble qu'à la base, la conception est un peu bizarre...

Tu as essayé de réimporter tes objets dans une base vierge ?

Domi2

[Eruil]

en fait il s'agit du suivi du dernier courrier (donc aucun interêt d'avoir un sous formulaire dans ce cas-là) mais bon comme je disais dans mon premier post je pars d'une appli déjà existante .... même si je me dis que j'aurais peut-etre eu plus vite fait de tout refaire.

Je viens de terminer l'import de tous les objets dans un nouveau fichier access. C'était barbant. maintenant je n'ai plus qu'a attendre la prochaine panne pour leur faire tester ou alors attendre demain. En tout cas j'y aurais au moins gagner quelque centaine de Ko sur le poids de la base frontale.

[Eruil]

Tout à l'heure au moment de l'un des blocages fatidiques, je suis allé voir les fichiers ouverts sur le serveur et j'ai remarqué que l'un des utilisateurs avaient 40 verrous sur le fichier .ldb correspondant à ma base dorsale (contre 4 pour les autres utilisateurs). J'ai clos la connexion de l'ordinateur en question et la base s'est débloquée.

Ma question est : Pourquoi 40 verrous ?? N'est-ce pas énorme ?

[loufab]

Bonjour,

Avant de fermer "l'utilisateur et les 40 verrous" tu devrais aller y faire un tour et regarder comment il utilise l'application. Il se peut qu'il utilise un formulaire ou autre objet qui verrouille 40 enregistrements d'un coup (une bourde dans le dev).
Comme il se peut également qu'il n'ai pas un poste à jour (version du Jet...)

Cordialement,

[Eruil]

Comme il se peut également qu'il n'ai pas un poste à jour (version du Jet...)

Impossible car tous les postes sont strictement identiques (même matériel et même Ghost et aucne action possible sur le système par l'utilisateur)

Tu devrais aller y faire un tour et regarder comment il utilise l'application

Si la scène se reproduit j'irais voir demain

un formulaire ou autre objet qui verrouille 40 enregistrements d'un coup

Est-ce que cela pourrais correspondre à un verrouillage par page ? Car auquel cas j'ai pourtant positionné le champ verrouillage à Enr modifié

[Eruil]

en désespoir de cause, j'ai essayé de faire une truc (l'inverse de ce qui doit être fait) : j'ai regroupé les données et les applications dans un meme fichier access (exit le modele frontale-dorsale) et j'ai mis ce fichier dans un dossier partagé.

la surprise est que je n'ai quasiment plus aucun blocage ! de l'ordre de 4 blocages de l'heure avant contre entre 5 et 10 dans la journée avec ce nouveau modèle (même si c'est encore trop, c'est déjà mieux).

Je suis un peu dégouté et hébété puisque depuis que je parcours le web et les forums à la recherche d'infos sur access je vois que le modèle frontal-dorsal fait l'unanimité pour les applis multi-utilisateurs.

j'aimerais savoir pourquoi le modèle frontale-dorsale marche moins bien dans mon cas ?

[Domi2]

Re,

j'aimerais savoir pourquoi le modèle frontale-dorsale marche moins bien dans mon cas ?

Ca ne vas pas durer longtemps

Un autre essai à faire...

Tu te fais une copie de ta base, et tu te refais une frontale / dorsale, mais en local. Puis tu l'essaies une heure...

Il me semble que si tu n'as pas de plantage, cela exlura un problème de l'application elle-même. Là, je pense à une procédure ou fonction qui s'exécuterai sur une propriété du style avant insertion, et qui poserai problème.

Si tu as la possibilité de de poster ton appli avec un jeu de données de test, je veux bien essayer de jeter un coup d'oeil, le week-end est long.

Domi2

[Eruil]

oui mais si je teste tout seul dans mon coin, ça planteras pas. C'est uniquement quand il y a plusieurs utilisateurs que ça bloque malheureusement (et donc pas facile pour tester par moi meme)

Si tu as la possibilité de de poster ton appli avec un jeu de données de test, je veux bien essayer de jeter un coup d'oeil, le week-end est long.

Je te remercie car je désespère vraiment mais tu risque d'etre surpris par l'appli qui a été developpé par plusieurs personnes successives et qui au final est devenu une usine à gaz. Je te la posterais après le déjeuner

merci encore

bon ap'

[Domi2]

Re,

Surpris, moi ? Il en faudra beaucoup

Encore une idée...

Le nombre de tentatives de mise à jour.

L'application modifie l'option à 5. Je ne ne suis pas grand connaisseur. En théorie, cela devrait améliorer les performances lors de l'utilisation de la base par plusieurs utilisateurs, mais le réglage par défaut est à 2.

Il serait peut-être intéressant de reprndre cette valeur pour voir si cela à une incidence (positive ou négative).

D'autre part, je ne crois pas que tu aie spécifié un point qui peut avoir son importance.

Ces plantages à répétition sont-ils récents ou l'application a toujours eu ce genre de problème ?

Domi2

[Eruil]

L'application modifie l'option à 5. Je ne ne suis pas grand connaisseur. En théorie, cela devrait améliorer les performances lors de l'utilisation de la base par plusieurs utilisateurs, mais le réglage par défaut est à 2.

Oui je l'ai monté à 5 en me disant que peut-etre ça reglerait le souci mais ça ne l'a pas règlé

D'autre part, je ne crois pas que tu aie spécifié un point qui peut avoir son importance.

je ne comprends pas ce que tu veux dire

Ces plantages à répétition sont-ils récents ou l'application a toujours eu ce genre de problème ?

J'ai repris l'appli il y a un mois environ (c'était une base partagée qui n'était pas fractionnée en frontale-dorsale) et à cette époque ça plantait déjà, mais moins que maintenant (4 ou 5 fois par jour)