Discussion :

[myseb]

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.

[Benjamin GAGNEUX]

Salut et bienvenue sur Developpez.com

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

[myseb]

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

[Benjamin GAGNEUX]

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+

[myseb]

merci pour le coup de main....

je ne suis pas assez calé je laisse tomber tant pis pour moi...

[Barbibulle]

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 :

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 :

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

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'

[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...)

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

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...

[Barbibulle]

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 :

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

1
2
3
4
SELECT CODEARTIC, COUNT(*) AS NOMBRE_DE_DOUBLES
  FROM   B_ART
  GROUP  BY CODEARTIC
  HAVING COUNT(*) > 1

[myseb]

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 ?

[Barbibulle]

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

[myseb]

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 ?