Précédent   Forum des professionnels en informatique > Bases de données > Firebird > Outils
Outils Forum d'entraide sur les outils tiers pour Firebird
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 30/10/2004, 14h08   #1
Invité de passage
 
Inscription : septembre 2004
Messages : 6
Détails du profil
Informations forums :
Inscription : septembre 2004
Messages : 6
Points : 0
Points : 0
Par défaut Problème de basckup Restore avec IBCONSOLE

Bonjour,

avant d'écrire ce post j'ai parcouru ce forum pour voir si je pouvais trouver de l'aide, mais n'ayant rien trouvé je me lance...

Voici mon problème :

je suis sous interbase 6.5, chaque semaine je fais un backup restore de ma base pour la rafraîchir car elle grossit énormément (70Mo).
Ayant lu cette astuce sur les "bons plans d'interbase", il est vrai qu'après ma base est plus lègère !

Je fais cette opération à partir de IBConsole et habituellement tout ce passe facilement, or cette fois ci j'ai eu un message d'erreur lors du restore qui est le suivant :

"Error 335544342
Action cancelled by trigger (3) to preserve data integrity
Cannot deactivate primary index"

et le restore s'arrête sur :

gbak: creating indexes
gbak: cannot commit index RDB$FOREIGN1949
gbak: ERROR: attempt to store duplicate value (visible to active transactions) in unique index "RDB$PRIMARY44"

visiblement une donnée de ma base m'empêcherait de poursuivre le restore. Mais je veux bien réparer la donnée mais je ne sais pas comment la trouver !

Donc si quelqu'un pouvais me donner un petit coup de main cela serait cool.

C'est mon premier post car jusqu'à présent j'ai réussi à trouver de l'aide via les autres post, ou sur le site developpez.com qui m'a beaucoup appris sur SQL. J'utilise SQL au boulot pour faire des requètes simples mais comme dans beaucoup de boîte il faut "s'autoformer" pour pouvoir assurer un minimum...

Cordialement votre.
myseb est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 01/11/2004, 19h59   #2
Rédacteur
 
Inscription : janvier 2004
Messages : 2 123
Détails du profil
Informations personnelles :
Âge : 31

Informations forums :
Inscription : janvier 2004
Messages : 2 123
Points : 1 977
Points : 1 977
Salut et bienvenue sur Developpez.com

Citation:
ERROR: attempt to store duplicate value (visible to active transactions) in unique index "RDB$PRIMARY44"
Cela signifie que deux enregistrements stockés ont dans le champs indexé et unique des valeurs identiques...

Je ne connais pas IBConsole mais en utilisant les IBX : IBRestoreService, il existe une option DeactivateIndexes qui permettrait probablement de contourner le problème.

en espérant que cela pourra t'aider ...
a bientot
__________________
Ancien pseudo : yobenzen

Recherche un emploi de Chef de Projet ou Développeur en Normandie
Delphi/Oracle/Interbase
Migration vers symfony

CV :
- LinkedIn
- Viadeo
Benjamin GAGNEUX est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 01/11/2004, 20h45   #3
Invité de passage
 
Inscription : septembre 2004
Messages : 6
Détails du profil
Informations forums :
Inscription : septembre 2004
Messages : 6
Points : 0
Points : 0
Par défaut Merci pour la Réponse mais...

Désolé je suis vraiment une quiche...mais c'est quoi les IBX ???

et puis quelques part plutôt que de contourner le problème je préferai avoir une méthode pour réparer les données.

Merci quand même
myseb est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 01/11/2004, 21h17   #4
Rédacteur
 
Inscription : janvier 2004
Messages : 2 123
Détails du profil
Informations personnelles :
Âge : 31

Informations forums :
Inscription : janvier 2004
Messages : 2 123
Points : 1 977
Points : 1 977
Salut,

IBX = InterBase Express, c'est la gamme de composant InterBase livré avec Delphi (InterBase et InterBase Admin)

Je pense que le seul moyen de réparer le problème c'est :

restorer la base de données en désactivant les indexes
puis faire une recherche de doublons sur les indexes afin de supprimer l'enregistrement posant problème.

Voila, je ne peux pas trop t'en dire plus car ... je n'en sais pas plus...
A+
__________________
Ancien pseudo : yobenzen

Recherche un emploi de Chef de Projet ou Développeur en Normandie
Delphi/Oracle/Interbase
Migration vers symfony

CV :
- LinkedIn
- Viadeo
Benjamin GAGNEUX est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 01/11/2004, 21h26   #5
Invité de passage
 
Inscription : septembre 2004
Messages : 6
Détails du profil
Informations forums :
Inscription : septembre 2004
Messages : 6
Points : 0
Points : 0
merci pour le coup de main....

je ne suis pas assez calé je laisse tomber tant pis pour moi...
myseb est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 02/11/2004, 10h03   #6
Membre Expert
 
Avatar de Barbibulle
 
Frédéric
Inscription : octobre 2002
Messages : 1 722
Détails du profil
Informations personnelles :
Nom : Frédéric
Âge : 42

Informations forums :
Inscription : octobre 2002
Messages : 1 722
Points : 2 025
Points : 2 025
La base avec lequel vous travaillez et dont vous avez fait un backup doit en effet avoir un probleme et ce n'est hélas que lors du restore que vous vous en appercevez.

Donc pour retrouver les données qui posent probleme il faut partir des informations contenues dans le message d'erreur :

Citation:
gbak: creating indexes
gbak: cannot commit index RDB$FOREIGN1949
gbak: ERROR: attempt to store duplicate value (visible to active transactions) in unique index "RDB$PRIMARY44"
Je rechercherai donc le primary44 pour savoir à quel table il correspond et puis faire une requete pour savoir s'il y a en effet des doublons.

Pour trouver la table qui pose probleme :
Code :
1
2
3
4
SELECT RDB$CONSTRAINT_NAME, RDB$CONSTRAINT_TYPE, RDB$RELATION_NAME, RDB$DEFERRABLE, RDB$INITIALLY_DEFERRED, RDB$INDEX_NAME
FROM RDB$RELATION_CONSTRAINTS
WHERE
RDB$INDEX_NAME ='RDB$PRIMARY44'
Barbibulle est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 02/11/2004, 12h06   #7
Invité de passage
 
Inscription : septembre 2004
Messages : 6
Détails du profil
Informations forums :
Inscription : septembre 2004
Messages : 6
Points : 0
Points : 0
bonjour Barbibulle,

merci pour votre requète, elle permet de me dire que primary44 fait référence à la table "B_ART" .

Le champ indexé sur ma table semble être un champ appelé "CODEARTIC" mais je n'ai pas de doublons (enfin je crois...)

Question, est-il possible de migrer mes datas vers une base vide ???

Citation:
La base avec lequel vous travaillez et dont vous avez fait un backup doit en effet avoir un probleme et ce n'est hélas que lors du restore que vous vous en appercevez
Question => est-il possible de savoir avant lorsque ma base part en vrille ?

Autre Question => ma base risque t'elle d'être inutilisable ?


Merci pour votre aide !

Pas évident de se servir d'interbase sans formation...
myseb est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 02/11/2004, 16h11   #8
Membre Expert
 
Avatar de Barbibulle
 
Frédéric
Inscription : octobre 2002
Messages : 1 722
Détails du profil
Informations personnelles :
Nom : Frédéric
Âge : 42

Informations forums :
Inscription : octobre 2002
Messages : 1 722
Points : 2 025
Points : 2 025
Citation:
Envoyé par myseb
bonjour Barbibulle,

merci pour votre requète, elle permet de me dire que primary44 fait référence à la table "B_ART" .

Le champ indexé sur ma table semble être un champ appelé "CODEARTIC" mais je n'ai pas de doublons (enfin je crois...)
Croire ne suffit hélas pas, il faut en être certain. Si vous avez une erreur c'est bien qu'il y a un probleme.
La requête ci dessous vous permettra de connaitre les codeartic qui seraient en doubles.
Code :
1
2
3
4
SELECT CODEARTIC, COUNT(*) AS NOMBRE_DE_DOUBLES
  FROM   B_ART
  GROUP  BY CODEARTIC
  HAVING COUNT(*) > 1
Barbibulle est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 02/11/2004, 19h47   #9
Invité de passage
 
Inscription : septembre 2004
Messages : 6
Détails du profil
Informations forums :
Inscription : septembre 2004
Messages : 6
Points : 0
Points : 0
arg!

j'avais malheureusement raison, il n'y a pas de double sur cette table...

???

le gros mystère ???

j'ai vu que RDB$FOREIGN1949 fait référence à une table vide nommée E_OF2

je ne pige pas ?

y-a t'il un danger pour la stabilité de ma base ?
myseb est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 03/11/2004, 14h39   #10
Membre Expert
 
Avatar de Barbibulle
 
Frédéric
Inscription : octobre 2002
Messages : 1 722
Détails du profil
Informations personnelles :
Nom : Frédéric
Âge : 42

Informations forums :
Inscription : octobre 2002
Messages : 1 722
Points : 2 025
Points : 2 025
Autre piste vous avez une clé etrangère dans votre table qui pointe vers un enregistrement qui n'existe plus.

Il n'y a pas de danger. C'est juste que vous pouvez plus faire de backup/restore.... Si vous ne trouvez pas ça sans danger, c'est vous qui voyez
Barbibulle est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 04/11/2004, 14h48   #11
Invité de passage
 
Inscription : septembre 2004
Messages : 6
Détails du profil
Informations forums :
Inscription : septembre 2004
Messages : 6
Points : 0
Points : 0
Merci Barbibulle pour votre coup de patte.

Je repars d'une base vide, je transfère toutes mes données.


Dernière question, le fait de faire un backup Restore permet-il d'accélerer les interrogations ?
myseb est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 07h50.


 
 
 
 
Partenaires

Hébergement Web