Discussion :

[What]

Bonjour

Je rencontre un souci que je ne parviens pas à résoudre (3 jours que je cherche).

J'ai développé une application sous delphi, et avec une base de donnée FireBird 2.1

Tout fonctionnait bien depuis des mois.

Puis j'ai eu besoin d'un nouveau champ dans la base. Je l'ai donc ajouté en utilisant le soft EMS Firebird Manager. Le champ a bien été ajouté, il semble fonctionner. Pourtant depuis, je rencontre un phénomène très étrange :

Je peux créer un nouvel enregistrement dans mon application.
Mais si j'édite ce nouvel enregistrement durant la même session, les modifications apportées ne sont pas prises en compte. Un peu comme si elles ne se commitaient pas. Je suis obligé de fermer l'application, de la relancer, et seulement alors, les modifications que j'apporte au nouvel enregistrement sont prises en compte.

Je n'avais pas ce souci avant. Comment l'ajout d'un champ dans la base peut-il induire un tel bug ?

Pour éclaircir la situtation et essayer de comprendre, j'ai supprimé le nouveau champ. L'application est revenue à la normale et refonctionna bien...
J'ai alors recréé un champ "bidon" de type varchar tout simple, et le bug est revenu dans mon application.

J'ai supprimé ce champ, tout est redevenu normal.Nouveau test : je recrée un champ integer, le bug revient... ETC. ...

Bref, je peux reproduire l'erreur à chaque fois et j'ai donc bien identifié le souci : ajouter un champ à ma base, aussi simple soit-il, ne servant même pas dans un index, et complètement indépendant en termes d'intégrité référentielle, cela provoque un souci dans les transactions entre la base et mon application.

Avez-vous déjà rencontré ce problème ?
Avez-vous des pistes pour trouver une solution. Car il va sans dire que mon application et ses futures extensions sont fortement compromises si je ne peux plus ajouter de champs à la base...


Merci pour votre aide.

[makowski]

tout ton problème ne peux venir que de ton application
voir le bon forum relatif à ton langage utilisé

[What]

Merci pour ton avis, mais je ne le partage pas. Enfin a priori. Pour cette raison :

Mon appli fonctionne parfaitement avant ajout du champ. Puis j'ajoute le champ dans la base, sans recompiler mon appli. Donc l'appli n'a pas connaissance du nouveau champ, elle ne bouge pas. Et pourtant, après ajout du champ, je peux même affirmer, de n'importe quel nouveau champ dans la table (unique table), même bidon, les soucis de transactions apparaissent, quand je relance l'appli, même si elle n'a pas été recompilée...

Voilà pourquoi je persiste à penser à un bug sur firebird...
D'autant plus que je maîtrise plutôt bien Delphi, et ce depuis 14 ans...


D'autres pistes ?

Firebird 2.1
Delphi 2005

[What]

Pour approfondir mes tests, j'ai recréé la base de donnée, et j'ai utilisé EMS Firebird manager pour récupérer les données de l'ancienne base vers la nouvelle.

J'ai ensuite créé sur la nouvelle base, le nouveau champ dont j'avais besoin. ET j'ai relancé mon appli. Et tout fonctionne bien. Donc je confirme, il devait y avoir un souci sur la base de données.

Mon souci est donc partiellement résolu. Partiellement, car quand j'ai exporté l'ancienne table sous forme de "insert statement", les données situées dans les champs de type blob n'ont pas été exportées, ni importées dans la nouvelle base.

D'où nouvelle question : comment exporter des données de la base A, dans la base B, sans perdre les blobs, et sans programmer de moulinette. En gros, comment le faire en sql ? Peut-on faire une sorte de :

Code :

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

1
2
 
"insert baseB.table1 select * from baseA.table1"

Merci pour votre aide

[makowski]

Voilà pourquoi je persiste à penser à un bug sur firebird...

et moi clairement à un bug entre le clavier et la chaise

franchement, un peu de sérieux
des bug dans Firebird il y en a, mais pas ce que tu décris.

[What]

et moi clairement à un bug entre le clavier et la chaise

franchement, un peu de sérieux

Ça n'existe plus la courtoisie ici ? Dommage...

Du reste, le fait qu'un bug n'a pas encore été recensé ici, ou rencontré, ne veut pas dire qu'il n'existe pas...


Tu peux étoffer afin que je comprenne en quoi ça ne peut être la base, au regard du résultat de mes tests qui n'impliquent pas l'appli ?

Et pour le select, une idée ?

Ou tu restes juste sur de la désobligeance ?

[makowski]

Ça n'existe plus la courtoisie ici ? Dommage...

si, mais franchement ton

D'autant plus que je maîtrise plutôt bien Delphi, et ce depuis 14 ans...

ne mérite pas autre chose

d'autant que dans la description de ton problème, tu n'expliques absolument rien de ce que ton programme fait et comment
ni comment tu gères tes transactions, ni quand et comment tu commit l'ajout des champs dans la base.

Et franchement, dire

c'est un bug de Firebird

parce que tu as 14 ans de pratique de Delphi, me fais rire
le code de Firebird date de 1984, est utilisé par des millions de personnes dans le monde, donc si l'ajout d'un champ dans une table créait des

soucis de transactions

(d'ailleurs quels soucis de transaction ?), cela se saurait ...

Au passage juste dire :

Mais si j'édite ce nouvel enregistrement durant la même session, les modifications apportées ne sont pas prises en compte. Un peu comme si elles ne se commitaient pas. Je suis obligé de fermer l'application, de la relancer, et seulement alors, les modifications que j'apporte au nouvel enregistrement sont prises en compte.

Prouve parfaitement que ton application ne fait le commit qu'à la fermeture de ta connexion à la base, donc que tu gère mal les transactions dans ton appli et ne décide pas explicitement de toi même de quand les commit doivent être faits.

[What]

Je n'ai pas voulu te froisser avec cette phrase, j'ai juste voulu écarter une piste qui ne me semblait pas la bonne. Désolé si je n'ai pas passé le bon message.

C'est juste que j'en suis à plus de 10 développements Firebird/delphi, et que c'est la première fois que je rencontre le souci. La seule différence, c'est que j'utilise pour la première fois firebird 2.1, alors qu'auparavant j'utilisais la version 1.5. D'où la direction vers firebird pour identifier un souci. Pas par auto suffisance de ma part pour ma maîtrise de l'outil...

Enfin, pour la gestion des transactions, je les gère bien moi-même. Par "commitRetaining" dans delphi. À chaque Update ou insert, et non pas à la fermeture de l'application.

Enfin, j'ai pu recréer le même problème sous ems Firebird manager. J'ai inséré un nouvel enregistrement, puis commit. Ensuite, update de l'enregistrement, puis commit... Enfin, select sur l'enregistrement créé puis modifié : l'enregistrement est bien présent, mais la modification apportée sur un champ (n'importe quel champ), n'est pas présente. Par contre, je n'ai pas le souci si je recréé la base de toutes pièces et importe les enregistrements de l'autre base. Voilà pourquoi j'écarte Delphi et mon appli du champ d'investigation. Pas par prétention pour mon développement, juste par déduction.

PS : j'ai l'impression de t'avoir froissé ou énervé, tel n'était pas mon but. Désolé si ce fut le cas. J'ai trop de respect pour toi, je connais tes compétences, et je ne viens pas ici faire le prétentieux...Cdlt.

[makowski]

franchement, ce que tu dis est incomprehensible

tu dis :
start transaction;
Alter table add ..
commit;
start transaction;
insert into table;
commit;
start transaction;
update table;
commit;
start transaction;
select ; -- là problème ?

Là j'ai franchement du mal à te croire.

Mais as tu vérifié la bonne santé de ta base ?


ps Commit Retaining c'est mal je l'ai expliqué x fois dans ce forum

[What]

franchement, ce que tu dis est incomprehensible

tu dis :
start transaction;
Alter table add ..
commit;
start transaction;
insert into table;
commit;
start transaction;
update table;
commit;
start transaction;
select ; -- là problème ?

Ton résumé est bon, c'est exactement ce qu'il se passe. À un détail près : je crée et j'édite ensuite le nouvel enregistrement dans la même transaction... Chose qui ne posait pas de souci avant l'insertion du nouveau champ. Depuis que j'ai ajouté ce champ, le select de fin renvoie bien l'enregistrement créé, mais pas la modification de celui-ci...

Là je viens de recréer la table sur une nouvelle base créée sous firebird 2.1, et je n'ai plus le souci. J'ai remonté les données, mais bon, j'ai perdu les blobs. Tant pis pas si grave.

Alors effectivement, ma base originale est peut-être corrompue... Elle avait été créée sous Firebird 1.5, puis tourne maintenant avec le moteur 2.1. Mais là ça dépasse ma compétence. Ou alors mon outil EMS, avec lequel j'ai tout créé, tout maintenu, tout édité, a eu un souci ?

Bon, étrange. Merci pour ton aide en tout cas.


PS : le commit retaining n'est pas bien ? Je l'utilisais parce que en commit pur, l'appli reprend la main qu'après 2.4 secs (0.4 en commit retaining). Donc lors de longue saisie, l'opérateur perd en productivité...

[makowski]

PS : le commit retaining n'est pas bien ? Je l'utilisais parce que en commit pur, l'appli reprend la main qu'après 2.4 secs (0.4 en commit retaining). Donc lors de longue saisie, l'opérateur perd en productivité...

Ce n'est absolument pas normal
ton programme ou tes composants ont vraiment un problème

[What]

Ok... Bon, je vais revoir tout ça de plus près.

Merci à toi.

[JustMe]

J'ai appris au cours de cette discussion qu'il ne fallait pas ouvrir tous les messages du forum