[Danger] mysterieuse disparition de clef et relations
4 réponses
Loutox
Salut à tous et joyeux noel
Avec Access, un probleme inquietant est apparu :
10 utilisateurs utilisent chacun en local une base "avant plan" (base avec
tables liées, code, forms, ect..)
les bases "avant plan" pointent toutes sur une base "arriere plan" (cette
base, située sur serveur de fichiers, contient uniquement les tables)
le probleme est qu'une des tables de la base arriere plan a perdu sa cle
primaire et ses relations avec les autres tables (le champ de la clef existe
toujours, mais n'est plus une clef)
Ceci peut avoir 2 raisons :
A/ Sabotage ou erreur de manip d'un utilisateur (Dans le contexte cette
hypothese me parait peu probable)
B/ Probleme de fiabilité d'access (du à des defaillances du reseau ? ou à
autre chose ?)
En furetant dans les archives je n'ai eu que des infos floues à propos de ce
genre de problème, aussi si vous avez deja eu affaire à (ou entendu parler
de) ce genre de probleme, cela m'interesse d'avoir votre avis
PS :
La date de modification de la table qui a perdu sa cle est inchangée par
rapport à mon versionning, ce qui semble ecarter la theorie A/ et aller dans
le sens de B/.
Ce probleme, qui a failli generer une catastrophe (et a à moitié gaché un
reveillon) me parait très important car il touche à la fiabilité d'access en
utilisation multi-utilisateurs.
Si ce fil n'obtient pas de reponses significatives, je me permettrai de le
poster à nouveau après les fetes (car en ces periodes de vacances ce sujet
risque de passer inapercu)
(Le serveur est en xp pro, et les clients en w98, wme, wxp familial ou wxp
pro, le reseau n'est pas au top de la performance)
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
hm15
Bonjour Loutox,
il pourrait y avoir une 3e hypothèse : quelques lignes de code qui provoqueraient ce problème dans un cas particulier (lors de l'importation de données par exemple). D'autant qu'il semble y avoir plusieurs frontales qui pointent vers les tables.
Je suppose que tu as bien vérifié dans la table elle-même, depuis la base qui la contient. Si je dis cela, c'est que si on regarde les tables depuis la frontale, les clés semblent parfois ne pas y être, notamment si on est en train d'éditer quelque chose.
Toutefois, je pencherais pour : - un début de corruption de la base dorsale, dû peut-être à un arrêt intempestif de la base ou à la saisie erronée d'un enregistrement - ou encore un objet ou contrôle défectueux dans le formulaire de saisie des enregistrements de la table concernée La clé primaire a dû être effacée lors du compactage de la base et bien sûr les relations entre les tables n'ont pu être recréées. Ton point B/ en fait. Personnellement, j'importerais toutes les tables dans une base vierge et je remettrais la clé primaire et les relations bien sûr. Je crois que je vérifierais aussi le formulaire de saisie.
"Loutox" a écrit dans le message de news: 3fea3868$0$29058$
Salut à tous et joyeux noel
Avec Access, un probleme inquietant est apparu :
10 utilisateurs utilisent chacun en local une base "avant plan" (base avec tables liées, code, forms, ect..) les bases "avant plan" pointent toutes sur une base "arriere plan" (cette base, située sur serveur de fichiers, contient uniquement les tables)
le probleme est qu'une des tables de la base arriere plan a perdu sa cle primaire et ses relations avec les autres tables (le champ de la clef existe
toujours, mais n'est plus une clef)
Ceci peut avoir 2 raisons : A/ Sabotage ou erreur de manip d'un utilisateur (Dans le contexte cette hypothese me parait peu probable) B/ Probleme de fiabilité d'access (du à des defaillances du reseau ? ou à autre chose ?)
En furetant dans les archives je n'ai eu que des infos floues à propos de ce
genre de problème, aussi si vous avez deja eu affaire à (ou entendu parler de) ce genre de probleme, cela m'interesse d'avoir votre avis
PS : La date de modification de la table qui a perdu sa cle est inchangée par rapport à mon versionning, ce qui semble ecarter la theorie A/ et aller dans
le sens de B/.
Ce probleme, qui a failli generer une catastrophe (et a à moitié gaché un reveillon) me parait très important car il touche à la fiabilité d'access en
utilisation multi-utilisateurs. Si ce fil n'obtient pas de reponses significatives, je me permettrai de le poster à nouveau après les fetes (car en ces periodes de vacances ce sujet
risque de passer inapercu)
(Le serveur est en xp pro, et les clients en w98, wme, wxp familial ou wxp pro, le reseau n'est pas au top de la performance)
A bientot, Loutox
Bonjour Loutox,
il pourrait y avoir une 3e hypothèse : quelques lignes de code qui
provoqueraient ce problème dans un cas particulier (lors de l'importation de
données par exemple).
D'autant qu'il semble y avoir plusieurs frontales qui pointent vers les
tables.
Je suppose que tu as bien vérifié dans la table elle-même, depuis la base
qui la contient.
Si je dis cela, c'est que si on regarde les tables depuis la frontale, les
clés semblent parfois ne pas y être, notamment si on est en train d'éditer
quelque chose.
Toutefois, je pencherais pour :
- un début de corruption de la base dorsale, dû peut-être à un arrêt
intempestif de la base ou à la saisie erronée d'un enregistrement
- ou encore un objet ou contrôle défectueux dans le formulaire de saisie des
enregistrements de la table concernée
La clé primaire a dû être effacée lors du compactage de la base et bien sûr
les relations entre les tables n'ont pu être recréées.
Ton point B/ en fait.
Personnellement, j'importerais toutes les tables dans une base vierge et je
remettrais la clé primaire et les relations bien sûr.
Je crois que je vérifierais aussi le formulaire de saisie.
"Loutox" <pasdepub_pour__loutox@free.fr> a écrit dans le message de news:
3fea3868$0$29058$636a55ce@news.free.fr...
Salut à tous et joyeux noel
Avec Access, un probleme inquietant est apparu :
10 utilisateurs utilisent chacun en local une base "avant plan" (base avec
tables liées, code, forms, ect..)
les bases "avant plan" pointent toutes sur une base "arriere plan" (cette
base, située sur serveur de fichiers, contient uniquement les tables)
le probleme est qu'une des tables de la base arriere plan a perdu sa cle
primaire et ses relations avec les autres tables (le champ de la clef
existe
toujours, mais n'est plus une clef)
Ceci peut avoir 2 raisons :
A/ Sabotage ou erreur de manip d'un utilisateur (Dans le contexte cette
hypothese me parait peu probable)
B/ Probleme de fiabilité d'access (du à des defaillances du reseau ? ou à
autre chose ?)
En furetant dans les archives je n'ai eu que des infos floues à propos de
ce
genre de problème, aussi si vous avez deja eu affaire à (ou entendu parler
de) ce genre de probleme, cela m'interesse d'avoir votre avis
PS :
La date de modification de la table qui a perdu sa cle est inchangée par
rapport à mon versionning, ce qui semble ecarter la theorie A/ et aller
dans
le sens de B/.
Ce probleme, qui a failli generer une catastrophe (et a à moitié gaché un
reveillon) me parait très important car il touche à la fiabilité d'access
en
utilisation multi-utilisateurs.
Si ce fil n'obtient pas de reponses significatives, je me permettrai de le
poster à nouveau après les fetes (car en ces periodes de vacances ce
sujet
risque de passer inapercu)
(Le serveur est en xp pro, et les clients en w98, wme, wxp familial ou wxp
pro, le reseau n'est pas au top de la performance)
il pourrait y avoir une 3e hypothèse : quelques lignes de code qui provoqueraient ce problème dans un cas particulier (lors de l'importation de données par exemple). D'autant qu'il semble y avoir plusieurs frontales qui pointent vers les tables.
Je suppose que tu as bien vérifié dans la table elle-même, depuis la base qui la contient. Si je dis cela, c'est que si on regarde les tables depuis la frontale, les clés semblent parfois ne pas y être, notamment si on est en train d'éditer quelque chose.
Toutefois, je pencherais pour : - un début de corruption de la base dorsale, dû peut-être à un arrêt intempestif de la base ou à la saisie erronée d'un enregistrement - ou encore un objet ou contrôle défectueux dans le formulaire de saisie des enregistrements de la table concernée La clé primaire a dû être effacée lors du compactage de la base et bien sûr les relations entre les tables n'ont pu être recréées. Ton point B/ en fait. Personnellement, j'importerais toutes les tables dans une base vierge et je remettrais la clé primaire et les relations bien sûr. Je crois que je vérifierais aussi le formulaire de saisie.
"Loutox" a écrit dans le message de news: 3fea3868$0$29058$
Salut à tous et joyeux noel
Avec Access, un probleme inquietant est apparu :
10 utilisateurs utilisent chacun en local une base "avant plan" (base avec tables liées, code, forms, ect..) les bases "avant plan" pointent toutes sur une base "arriere plan" (cette base, située sur serveur de fichiers, contient uniquement les tables)
le probleme est qu'une des tables de la base arriere plan a perdu sa cle primaire et ses relations avec les autres tables (le champ de la clef existe
toujours, mais n'est plus une clef)
Ceci peut avoir 2 raisons : A/ Sabotage ou erreur de manip d'un utilisateur (Dans le contexte cette hypothese me parait peu probable) B/ Probleme de fiabilité d'access (du à des defaillances du reseau ? ou à autre chose ?)
En furetant dans les archives je n'ai eu que des infos floues à propos de ce
genre de problème, aussi si vous avez deja eu affaire à (ou entendu parler de) ce genre de probleme, cela m'interesse d'avoir votre avis
PS : La date de modification de la table qui a perdu sa cle est inchangée par rapport à mon versionning, ce qui semble ecarter la theorie A/ et aller dans
le sens de B/.
Ce probleme, qui a failli generer une catastrophe (et a à moitié gaché un reveillon) me parait très important car il touche à la fiabilité d'access en
utilisation multi-utilisateurs. Si ce fil n'obtient pas de reponses significatives, je me permettrai de le poster à nouveau après les fetes (car en ces periodes de vacances ce sujet
risque de passer inapercu)
(Le serveur est en xp pro, et les clients en w98, wme, wxp familial ou wxp pro, le reseau n'est pas au top de la performance)
A bientot, Loutox
Maxence HUBICHE
Bonjour !
Vérifies aussi que tu n'as pas une requête de création de table pour recréer ta table liée dans le frontal. J'ai vu ça une fois : Dans un frontal, une table liée, et une requête de création de table qui créait la même table que la table liée. Et ben de manière aléatoire, ca te met un de ces boxon dans ta base !!!!
Bonjour !
Vérifies aussi que tu n'as pas une requête de création de table pour recréer ta table liée dans le frontal.
J'ai vu ça une fois :
Dans un frontal, une table liée, et une requête de création de table qui créait la même table que la table liée.
Et ben de manière aléatoire, ca te met un de ces boxon dans ta base !!!!
Vérifies aussi que tu n'as pas une requête de création de table pour recréer ta table liée dans le frontal. J'ai vu ça une fois : Dans un frontal, une table liée, et une requête de création de table qui créait la même table que la table liée. Et ben de manière aléatoire, ca te met un de ces boxon dans ta base !!!!
Loutox
Bonjour Annette, (...)
D'autant qu'il semble y avoir plusieurs frontales qui pointent vers les tables.
Oui, ce sont toutes les memes,
Je suppose que tu as bien vérifié dans la table elle-même, depuis la base qui la contient.
Oui
Toutefois, je pencherais pour : - un début de corruption de la base dorsale, dû peut-être à un arrêt intempestif de la base ou à la saisie erronée d'un enregistrement
Effectivement Il y a eu à un moment un conflit d'enregistrement entre 2 utilisateurs qui a rendu l'ouverture de la table en question impossible dans la table dorsale. J'ai du compacter la base dorsale pour la reparer, et c'est sans doute à ce moment là que la clef a disparu, ce qui m'etonne est que suite à cet evenement la base a été utilisée sans probleme 15 jours avant le plantage d'hier (sans doute parce que les formulaires et procedures respectaient bien les regles d'integrité). Je vais effectuer des tests pour verifier cette hypothese.
- ou encore un objet ou contrôle défectueux dans le formulaire de saisie des
enregistrements de la table concernée
controle defectueux ? aurais tu un exemple stp, je ne comprends pas ce que c'est.
La clé primaire a dû être effacée lors du compactage de la base et bien sûr
les relations entre les tables n'ont pu être recréées. Ton point B/ en fait.
yes.
Personnellement, j'importerais toutes les tables dans une base vierge et je
remettrais la clé primaire et les relations bien sûr.
C'est ce que j'ai fait en catastrophe vendredi soir avant d'attaquer le champagne :-(
Je crois que je vérifierais aussi le formulaire de saisie.
Ceci avait été fait pour resoudre le conflit entre utilisateurs d'il y a 15 jours.
Bonnes fêtes quand même,
Bonne fetes à toi aussi et merci pour ton exposé clair qui m'a aidé à rationaliser le diagnostic
Apparemment la lecon à retenir est qu'il faut verifier la structure des données (index, clefs, références) après un "compactage-réparation", j'ignorais cela.
"Bon bout d'an"
Loutox http://www.lgis.fr
Bonjour Annette,
(...)
D'autant qu'il semble y avoir plusieurs frontales qui pointent vers les
tables.
Oui, ce sont toutes les memes,
Je suppose que tu as bien vérifié dans la table elle-même, depuis la base
qui la contient.
Oui
Toutefois, je pencherais pour :
- un début de corruption de la base dorsale, dû peut-être à un arrêt
intempestif de la base ou à la saisie erronée d'un enregistrement
Effectivement Il y a eu à un moment un conflit d'enregistrement entre 2
utilisateurs qui a rendu l'ouverture de la table en question impossible dans
la table dorsale.
J'ai du compacter la base dorsale pour la reparer, et c'est sans doute à ce
moment là que la clef a disparu, ce qui m'etonne est que suite à cet
evenement la base a été utilisée sans probleme 15 jours avant le plantage
d'hier (sans doute parce que les formulaires et procedures respectaient bien
les regles d'integrité).
Je vais effectuer des tests pour verifier cette hypothese.
- ou encore un objet ou contrôle défectueux dans le formulaire de saisie
des
enregistrements de la table concernée
controle defectueux ? aurais tu un exemple stp, je ne comprends pas ce que
c'est.
La clé primaire a dû être effacée lors du compactage de la base et bien
sûr
les relations entre les tables n'ont pu être recréées.
Ton point B/ en fait.
yes.
Personnellement, j'importerais toutes les tables dans une base vierge et
je
remettrais la clé primaire et les relations bien sûr.
C'est ce que j'ai fait en catastrophe vendredi soir avant d'attaquer le
champagne :-(
Je crois que je vérifierais aussi le formulaire de saisie.
Ceci avait été fait pour resoudre le conflit entre utilisateurs d'il y a 15
jours.
Bonnes fêtes quand même,
Bonne fetes à toi aussi et merci pour ton exposé clair qui m'a aidé à
rationaliser le diagnostic
Apparemment la lecon à retenir est qu'il faut verifier la structure des
données (index, clefs, références) après un "compactage-réparation",
j'ignorais cela.
D'autant qu'il semble y avoir plusieurs frontales qui pointent vers les tables.
Oui, ce sont toutes les memes,
Je suppose que tu as bien vérifié dans la table elle-même, depuis la base qui la contient.
Oui
Toutefois, je pencherais pour : - un début de corruption de la base dorsale, dû peut-être à un arrêt intempestif de la base ou à la saisie erronée d'un enregistrement
Effectivement Il y a eu à un moment un conflit d'enregistrement entre 2 utilisateurs qui a rendu l'ouverture de la table en question impossible dans la table dorsale. J'ai du compacter la base dorsale pour la reparer, et c'est sans doute à ce moment là que la clef a disparu, ce qui m'etonne est que suite à cet evenement la base a été utilisée sans probleme 15 jours avant le plantage d'hier (sans doute parce que les formulaires et procedures respectaient bien les regles d'integrité). Je vais effectuer des tests pour verifier cette hypothese.
- ou encore un objet ou contrôle défectueux dans le formulaire de saisie des
enregistrements de la table concernée
controle defectueux ? aurais tu un exemple stp, je ne comprends pas ce que c'est.
La clé primaire a dû être effacée lors du compactage de la base et bien sûr
les relations entre les tables n'ont pu être recréées. Ton point B/ en fait.
yes.
Personnellement, j'importerais toutes les tables dans une base vierge et je
remettrais la clé primaire et les relations bien sûr.
C'est ce que j'ai fait en catastrophe vendredi soir avant d'attaquer le champagne :-(
Je crois que je vérifierais aussi le formulaire de saisie.
Ceci avait été fait pour resoudre le conflit entre utilisateurs d'il y a 15 jours.
Bonnes fêtes quand même,
Bonne fetes à toi aussi et merci pour ton exposé clair qui m'a aidé à rationaliser le diagnostic
Apparemment la lecon à retenir est qu'il faut verifier la structure des données (index, clefs, références) après un "compactage-réparation", j'ignorais cela.
"Bon bout d'an"
Loutox http://www.lgis.fr
loloscott78
Bonjour,
J'ai exactement le meme probleme que vous. Avez vous résolu le probleme. Mes cles primaires sautent, je soupconne de plus en plus le réseau. Mais effectivement il est difficile d'avoir une réponse claire. Merci pour l'info.
----- Loutox a écrit : -----
Salut à tous et joyeux noel
Avec Access, un probleme inquietant est apparu :
10 utilisateurs utilisent chacun en local une base "avant plan" (base avec tables liées, code, forms, ect..) les bases "avant plan" pointent toutes sur une base "arriere plan" (cette base, située sur serveur de fichiers, contient uniquement les tables)
le probleme est qu'une des tables de la base arriere plan a perdu sa cle primaire et ses relations avec les autres tables (le champ de la clef existe toujours, mais n'est plus une clef)
Ceci peut avoir 2 raisons : A/ Sabotage ou erreur de manip d'un utilisateur (Dans le contexte cette hypothese me parait peu probable) B/ Probleme de fiabilité d'access (du à des defaillances du reseau ? ou à autre chose ?)
En furetant dans les archives je n'ai eu que des infos floues à propos de ce genre de problème, aussi si vous avez deja eu affaire à (ou entendu parler de) ce genre de probleme, cela m'interesse d'avoir votre avis
PS : La date de modification de la table qui a perdu sa cle est inchangée par rapport à mon versionning, ce qui semble ecarter la theorie A/ et aller dans le sens de B/.
Ce probleme, qui a failli generer une catastrophe (et a à moitié gaché un reveillon) me parait très important car il touche à la fiabilité d'access en utilisation multi-utilisateurs. Si ce fil n'obtient pas de reponses significatives, je me permettrai de le poster à nouveau après les fetes (car en ces periodes de vacances ce sujet risque de passer inapercu)
(Le serveur est en xp pro, et les clients en w98, wme, wxp familial ou wxp pro, le reseau n'est pas au top de la performance)
A bientot, Loutox
Bonjour,
J'ai exactement le meme probleme que vous. Avez vous résolu le probleme.
Mes cles primaires sautent, je soupconne de plus en plus le réseau.
Mais effectivement il est difficile d'avoir une réponse claire.
Merci pour l'info.
----- Loutox a écrit : -----
Salut à tous et joyeux noel
Avec Access, un probleme inquietant est apparu :
10 utilisateurs utilisent chacun en local une base "avant plan" (base avec
tables liées, code, forms, ect..)
les bases "avant plan" pointent toutes sur une base "arriere plan" (cette
base, située sur serveur de fichiers, contient uniquement les tables)
le probleme est qu'une des tables de la base arriere plan a perdu sa cle
primaire et ses relations avec les autres tables (le champ de la clef existe
toujours, mais n'est plus une clef)
Ceci peut avoir 2 raisons :
A/ Sabotage ou erreur de manip d'un utilisateur (Dans le contexte cette
hypothese me parait peu probable)
B/ Probleme de fiabilité d'access (du à des defaillances du reseau ? ou à
autre chose ?)
En furetant dans les archives je n'ai eu que des infos floues à propos de ce
genre de problème, aussi si vous avez deja eu affaire à (ou entendu parler
de) ce genre de probleme, cela m'interesse d'avoir votre avis
PS :
La date de modification de la table qui a perdu sa cle est inchangée par
rapport à mon versionning, ce qui semble ecarter la theorie A/ et aller dans
le sens de B/.
Ce probleme, qui a failli generer une catastrophe (et a à moitié gaché un
reveillon) me parait très important car il touche à la fiabilité d'access en
utilisation multi-utilisateurs.
Si ce fil n'obtient pas de reponses significatives, je me permettrai de le
poster à nouveau après les fetes (car en ces periodes de vacances ce sujet
risque de passer inapercu)
(Le serveur est en xp pro, et les clients en w98, wme, wxp familial ou wxp
pro, le reseau n'est pas au top de la performance)
J'ai exactement le meme probleme que vous. Avez vous résolu le probleme. Mes cles primaires sautent, je soupconne de plus en plus le réseau. Mais effectivement il est difficile d'avoir une réponse claire. Merci pour l'info.
----- Loutox a écrit : -----
Salut à tous et joyeux noel
Avec Access, un probleme inquietant est apparu :
10 utilisateurs utilisent chacun en local une base "avant plan" (base avec tables liées, code, forms, ect..) les bases "avant plan" pointent toutes sur une base "arriere plan" (cette base, située sur serveur de fichiers, contient uniquement les tables)
le probleme est qu'une des tables de la base arriere plan a perdu sa cle primaire et ses relations avec les autres tables (le champ de la clef existe toujours, mais n'est plus une clef)
Ceci peut avoir 2 raisons : A/ Sabotage ou erreur de manip d'un utilisateur (Dans le contexte cette hypothese me parait peu probable) B/ Probleme de fiabilité d'access (du à des defaillances du reseau ? ou à autre chose ?)
En furetant dans les archives je n'ai eu que des infos floues à propos de ce genre de problème, aussi si vous avez deja eu affaire à (ou entendu parler de) ce genre de probleme, cela m'interesse d'avoir votre avis
PS : La date de modification de la table qui a perdu sa cle est inchangée par rapport à mon versionning, ce qui semble ecarter la theorie A/ et aller dans le sens de B/.
Ce probleme, qui a failli generer une catastrophe (et a à moitié gaché un reveillon) me parait très important car il touche à la fiabilité d'access en utilisation multi-utilisateurs. Si ce fil n'obtient pas de reponses significatives, je me permettrai de le poster à nouveau après les fetes (car en ces periodes de vacances ce sujet risque de passer inapercu)
(Le serveur est en xp pro, et les clients en w98, wme, wxp familial ou wxp pro, le reseau n'est pas au top de la performance)
