Erreur 3260, modification impossible, vérrouillé par utilisateur A
4 réponses
Humphrey
Bonjour,
J'ai ce message de façon aléatoire dans une application VB6 utilisant des
bases ACCESS. Cette erreur arrive dans un réseau sur dix et de façon
aléatoire. Neuf réseaux sur dix marchent très bien.
Qui a une idée sur ce que je dois chercher, améliorer, modifier pour que les
utilsateurs ne soient plus emm... 10 fois par jour?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gerald
Bonjour, aléatoire et informatique, ca existe ? est ce que c'est toujours le meme user qui est emm... ? à quel moment se produit l'erreur (non, ce n'est pas aléatoire)? peut-on isoler la panne ? Vérifier les droits d'accés sur la base de données Accès à un composant de manière restreinte ? ...
difficile de trouver une solution pour le problème que tu rencontres sans être au coeur du dev. generalement, on se dit, pour gagner un peu de temps, que la gestion d'erreur n'est pas indispensable pour tel ou tel truc mais on s'apercoit que les utilisateurs finaux sont demeurés et arrivent à faire tourner de l'oeil une appli qui semble être blindée.
peut etre envisager de debugger l'application sur le poste client installer VB et le source de l'appli.
j'ai trouvé cet article, peut être y trouveras tu ton bonheur http://support.microsoft.com/default.aspx?scid=kb%3Bfr%3B113953
Gerald
"Humphrey" a écrit dans le message de news:
Bonjour,
J'ai ce message de façon aléatoire dans une application VB6 utilisant des bases ACCESS. Cette erreur arrive dans un réseau sur dix et de façon aléatoire. Neuf réseaux sur dix marchent très bien.
Qui a une idée sur ce que je dois chercher, améliorer, modifier pour que les utilsateurs ne soient plus emm... 10 fois par jour?
merci. -- Humphrey, Polytel mediqual+
Bonjour,
aléatoire et informatique, ca existe ?
est ce que c'est toujours le meme user qui est emm... ?
à quel moment se produit l'erreur (non, ce n'est pas aléatoire)?
peut-on isoler la panne ?
Vérifier les droits d'accés sur la base de données
Accès à un composant de manière restreinte ?
...
difficile de trouver une solution pour le problème que tu rencontres sans
être au coeur du dev.
generalement, on se dit, pour gagner un peu de temps, que la gestion
d'erreur n'est pas indispensable pour tel ou tel truc mais on s'apercoit que
les utilisateurs finaux sont demeurés et arrivent à faire tourner de l'oeil
une appli qui semble être blindée.
peut etre envisager de debugger l'application sur le poste client
installer VB et le source de l'appli.
j'ai trouvé cet article, peut être y trouveras tu ton bonheur
http://support.microsoft.com/default.aspx?scid=kb%3Bfr%3B113953
Gerald
"Humphrey" <Humphrey@discussions.microsoft.com> a écrit dans le message de
news: 453BBECF-DB2A-4E35-B225-C2DFEAF22830@microsoft.com...
Bonjour,
J'ai ce message de façon aléatoire dans une application VB6 utilisant des
bases ACCESS. Cette erreur arrive dans un réseau sur dix et de façon
aléatoire. Neuf réseaux sur dix marchent très bien.
Qui a une idée sur ce que je dois chercher, améliorer, modifier pour que
les
utilsateurs ne soient plus emm... 10 fois par jour?
Bonjour, aléatoire et informatique, ca existe ? est ce que c'est toujours le meme user qui est emm... ? à quel moment se produit l'erreur (non, ce n'est pas aléatoire)? peut-on isoler la panne ? Vérifier les droits d'accés sur la base de données Accès à un composant de manière restreinte ? ...
difficile de trouver une solution pour le problème que tu rencontres sans être au coeur du dev. generalement, on se dit, pour gagner un peu de temps, que la gestion d'erreur n'est pas indispensable pour tel ou tel truc mais on s'apercoit que les utilisateurs finaux sont demeurés et arrivent à faire tourner de l'oeil une appli qui semble être blindée.
peut etre envisager de debugger l'application sur le poste client installer VB et le source de l'appli.
j'ai trouvé cet article, peut être y trouveras tu ton bonheur http://support.microsoft.com/default.aspx?scid=kb%3Bfr%3B113953
Gerald
"Humphrey" a écrit dans le message de news:
Bonjour,
J'ai ce message de façon aléatoire dans une application VB6 utilisant des bases ACCESS. Cette erreur arrive dans un réseau sur dix et de façon aléatoire. Neuf réseaux sur dix marchent très bien.
Qui a une idée sur ce que je dois chercher, améliorer, modifier pour que les utilsateurs ne soient plus emm... 10 fois par jour?
merci. -- Humphrey, Polytel mediqual+
SAISAS
Bonjour,
voici ce que je comprends de ton problème : tu utilises des bases ACCESS partagées sur un réseau (sur un disque partagé?) en mode modification et plusieurs utilisateurs peuvent travailler en même temps sur la base de données.
Sauf erreur de ma part, les bases ACCESS sont des bases de données non partageables par plusieurs utilisateurs, la seule chose qui puisse marcher est d'utiliser plusieurs programmes sur une base ACCESS locale, et encore avec quelques inconvénients.
Ton problème survient donc lorsque deux utilisateurs ont la mauvaise idée de mettre à jour les données en même temps : un des deux est prié d'attendre que l'autre ait fini avant de travailler. Ce problème est connu depuis que l'informatique existe et correspond à ton diagnostic de panne aléatoire. Mauvaise nouvelle, plus ton progamme est utilisé, plus ton problème est fréquent, jusqu'à finir par rendre l'utilisation de ton application impossible.
Tu possèdes deux solutions :
1. continure à utiliser ACCESS et développer une usine à gaz pour assurer le partage des données. Quelques pistes : développer un serveur de données pour traiter les mises à jour, traiter l'erreur 3260 par programme (bon courage) ou utiliser HTML (mais nous sommes sur le foum VB ici)
2. changer de SGBD, en utilisant par exemple SQL Serveur (mais il y en a d'autres ...).
Bon courage.
"Humphrey" a écrit :
Bonjour,
J'ai ce message de façon aléatoire dans une application VB6 utilisant des bases ACCESS. Cette erreur arrive dans un réseau sur dix et de façon aléatoire. Neuf réseaux sur dix marchent très bien.
Qui a une idée sur ce que je dois chercher, améliorer, modifier pour que les utilsateurs ne soient plus emm... 10 fois par jour?
merci. -- Humphrey, Polytel mediqual+
Bonjour,
voici ce que je comprends de ton problème : tu utilises des bases ACCESS
partagées sur un réseau (sur un disque partagé?) en mode modification et
plusieurs utilisateurs peuvent travailler en même temps sur la base de
données.
Sauf erreur de ma part, les bases ACCESS sont des bases de données non
partageables par plusieurs utilisateurs, la seule chose qui puisse marcher
est d'utiliser plusieurs programmes sur une base ACCESS locale, et encore
avec quelques inconvénients.
Ton problème survient donc lorsque deux utilisateurs ont la mauvaise idée de
mettre à jour les données en même temps : un des deux est prié d'attendre que
l'autre ait fini avant de travailler. Ce problème est connu depuis que
l'informatique existe et correspond à ton diagnostic de panne aléatoire.
Mauvaise nouvelle, plus ton progamme est utilisé, plus ton problème est
fréquent, jusqu'à finir par rendre l'utilisation de ton application
impossible.
Tu possèdes deux solutions :
1. continure à utiliser ACCESS et développer une usine à gaz pour assurer le
partage des données. Quelques pistes : développer un serveur de données pour
traiter les mises à jour, traiter l'erreur 3260 par programme (bon courage)
ou utiliser HTML (mais nous sommes sur le foum VB ici)
2. changer de SGBD, en utilisant par exemple SQL Serveur (mais il y en a
d'autres ...).
Bon courage.
"Humphrey" a écrit :
Bonjour,
J'ai ce message de façon aléatoire dans une application VB6 utilisant des
bases ACCESS. Cette erreur arrive dans un réseau sur dix et de façon
aléatoire. Neuf réseaux sur dix marchent très bien.
Qui a une idée sur ce que je dois chercher, améliorer, modifier pour que les
utilsateurs ne soient plus emm... 10 fois par jour?
voici ce que je comprends de ton problème : tu utilises des bases ACCESS partagées sur un réseau (sur un disque partagé?) en mode modification et plusieurs utilisateurs peuvent travailler en même temps sur la base de données.
Sauf erreur de ma part, les bases ACCESS sont des bases de données non partageables par plusieurs utilisateurs, la seule chose qui puisse marcher est d'utiliser plusieurs programmes sur une base ACCESS locale, et encore avec quelques inconvénients.
Ton problème survient donc lorsque deux utilisateurs ont la mauvaise idée de mettre à jour les données en même temps : un des deux est prié d'attendre que l'autre ait fini avant de travailler. Ce problème est connu depuis que l'informatique existe et correspond à ton diagnostic de panne aléatoire. Mauvaise nouvelle, plus ton progamme est utilisé, plus ton problème est fréquent, jusqu'à finir par rendre l'utilisation de ton application impossible.
Tu possèdes deux solutions :
1. continure à utiliser ACCESS et développer une usine à gaz pour assurer le partage des données. Quelques pistes : développer un serveur de données pour traiter les mises à jour, traiter l'erreur 3260 par programme (bon courage) ou utiliser HTML (mais nous sommes sur le foum VB ici)
2. changer de SGBD, en utilisant par exemple SQL Serveur (mais il y en a d'autres ...).
Bon courage.
"Humphrey" a écrit :
Bonjour,
J'ai ce message de façon aléatoire dans une application VB6 utilisant des bases ACCESS. Cette erreur arrive dans un réseau sur dix et de façon aléatoire. Neuf réseaux sur dix marchent très bien.
Qui a une idée sur ce que je dois chercher, améliorer, modifier pour que les utilsateurs ne soient plus emm... 10 fois par jour?
merci. -- Humphrey, Polytel mediqual+
Humphrey
Ok, Ok,
Access n'est pas multiutilisateurs. Mais cela a toujours marché car le verrou est très temporaire et l'accès est temporisé (on peut règler dans la base de registre combien de temps Access attend que la base soit déverrouilée avant de retourner une erreur, mais je ne sais plus où). Le problème est que, dès lecture, update, new, la base doit se déverrouiller (c'est pas la base, ce sont les enregistrements autour de celui qui est accèdé) et que cela ne se fait pas. Il faut redémarrer tous les postes pour débloquer la situation. Sinon, il suffirait de sortir du programme, d'y retourner pour ne plus être bloqué. Ce n'est pas le cas. Je maintiens que c'est un souci réseau, mais lequel? -- Humphrey, Polytel mediqual+
Ok, Ok,
Access n'est pas multiutilisateurs. Mais cela a toujours marché car le
verrou est très temporaire et l'accès est temporisé (on peut règler dans la
base de registre combien de temps Access attend que la base soit déverrouilée
avant de retourner une erreur, mais je ne sais plus où).
Le problème est que, dès lecture, update, new, la base doit se déverrouiller
(c'est pas la base, ce sont les enregistrements autour de celui qui est
accèdé) et que cela ne se fait pas. Il faut redémarrer tous les postes pour
débloquer la situation. Sinon, il suffirait de sortir du programme, d'y
retourner pour ne plus être bloqué. Ce n'est pas le cas.
Je maintiens que c'est un souci réseau, mais lequel?
--
Humphrey, Polytel mediqual+
Access n'est pas multiutilisateurs. Mais cela a toujours marché car le verrou est très temporaire et l'accès est temporisé (on peut règler dans la base de registre combien de temps Access attend que la base soit déverrouilée avant de retourner une erreur, mais je ne sais plus où). Le problème est que, dès lecture, update, new, la base doit se déverrouiller (c'est pas la base, ce sont les enregistrements autour de celui qui est accèdé) et que cela ne se fait pas. Il faut redémarrer tous les postes pour débloquer la situation. Sinon, il suffirait de sortir du programme, d'y retourner pour ne plus être bloqué. Ce n'est pas le cas. Je maintiens que c'est un souci réseau, mais lequel? -- Humphrey, Polytel mediqual+
SAISAS
Bonjour,
ton souci est effectivement un souci réseau : c'est parce que tu utilises le réseau que tu provoques ces problèmes qui n'existeraient pas sur une base locale.
Je ne suis pas un spécialiste Access, mais lorsque plusieurs utilisateurs utilisent une même base sur un serveur, il me semble que les verrous sont gérés au niveau du fichier (par le gestionnaire de fichiers du serveur) et non au niveau du gestionnaire de base de données (à priori Microsoft Jet sur chacun des ordinateurs des utilisateurs).
Et ton diagnostic resemble fort à ce qu'on appelle une étreinte fatale : deux utilisateurs se bloquent l'un l'autre et il n'existe pas d'autre solution que de les planter tous les deux ...
A ta disposition pour plus de détails si tu le souhaites ...
"Humphrey" a écrit :
Ok, Ok,
Access n'est pas multiutilisateurs. Mais cela a toujours marché car le verrou est très temporaire et l'accès est temporisé (on peut règler dans la base de registre combien de temps Access attend que la base soit déverrouilée avant de retourner une erreur, mais je ne sais plus où). Le problème est que, dès lecture, update, new, la base doit se déverrouiller (c'est pas la base, ce sont les enregistrements autour de celui qui est accèdé) et que cela ne se fait pas. Il faut redémarrer tous les postes pour débloquer la situation. Sinon, il suffirait de sortir du programme, d'y retourner pour ne plus être bloqué. Ce n'est pas le cas. Je maintiens que c'est un souci réseau, mais lequel? -- Humphrey, Polytel mediqual+
Bonjour,
ton souci est effectivement un souci réseau : c'est parce que tu utilises le
réseau que tu provoques ces problèmes qui n'existeraient pas sur une base
locale.
Je ne suis pas un spécialiste Access, mais lorsque plusieurs utilisateurs
utilisent une même base sur un serveur, il me semble que les verrous sont
gérés au niveau du fichier (par le gestionnaire de fichiers du serveur) et
non au niveau du gestionnaire de base de données (à priori Microsoft Jet sur
chacun des ordinateurs des utilisateurs).
Et ton diagnostic resemble fort à ce qu'on appelle une étreinte fatale :
deux utilisateurs se bloquent l'un l'autre et il n'existe pas d'autre
solution que de les planter tous les deux ...
A ta disposition pour plus de détails si tu le souhaites ...
"Humphrey" a écrit :
Ok, Ok,
Access n'est pas multiutilisateurs. Mais cela a toujours marché car le
verrou est très temporaire et l'accès est temporisé (on peut règler dans la
base de registre combien de temps Access attend que la base soit déverrouilée
avant de retourner une erreur, mais je ne sais plus où).
Le problème est que, dès lecture, update, new, la base doit se déverrouiller
(c'est pas la base, ce sont les enregistrements autour de celui qui est
accèdé) et que cela ne se fait pas. Il faut redémarrer tous les postes pour
débloquer la situation. Sinon, il suffirait de sortir du programme, d'y
retourner pour ne plus être bloqué. Ce n'est pas le cas.
Je maintiens que c'est un souci réseau, mais lequel?
--
Humphrey, Polytel mediqual+
ton souci est effectivement un souci réseau : c'est parce que tu utilises le réseau que tu provoques ces problèmes qui n'existeraient pas sur une base locale.
Je ne suis pas un spécialiste Access, mais lorsque plusieurs utilisateurs utilisent une même base sur un serveur, il me semble que les verrous sont gérés au niveau du fichier (par le gestionnaire de fichiers du serveur) et non au niveau du gestionnaire de base de données (à priori Microsoft Jet sur chacun des ordinateurs des utilisateurs).
Et ton diagnostic resemble fort à ce qu'on appelle une étreinte fatale : deux utilisateurs se bloquent l'un l'autre et il n'existe pas d'autre solution que de les planter tous les deux ...
A ta disposition pour plus de détails si tu le souhaites ...
"Humphrey" a écrit :
Ok, Ok,
Access n'est pas multiutilisateurs. Mais cela a toujours marché car le verrou est très temporaire et l'accès est temporisé (on peut règler dans la base de registre combien de temps Access attend que la base soit déverrouilée avant de retourner une erreur, mais je ne sais plus où). Le problème est que, dès lecture, update, new, la base doit se déverrouiller (c'est pas la base, ce sont les enregistrements autour de celui qui est accèdé) et que cela ne se fait pas. Il faut redémarrer tous les postes pour débloquer la situation. Sinon, il suffirait de sortir du programme, d'y retourner pour ne plus être bloqué. Ce n'est pas le cas. Je maintiens que c'est un souci réseau, mais lequel? -- Humphrey, Polytel mediqual+
