Discussion :

[WebPac]

Bonjour tout le monde.
J'utilisais les composants dbXpress pour me connecter à Firebird, j'ai changé et suis passé aux composants IB natifs Firebird/Interbase.

J'ai plusieurs bases de données Firebird (2 en fait), je fait des rappatriements de données, dans un premier temps de la première base de données vers la seconde, puis de la seconde vers la seconde.
Et lorsque j'essaie d'ouvrir la seconde requête (pour le second rappatriement), j'ai ce message d'erreur :

invalid transaction handle (expecting explicit transaction start).

J'ai regardé l'état connecté des bases de données, si mes transactions sont actives et normalement, c'est bon de ce côté là.

Savez-vous ce que signifie ce message d'erreur ? Afin de pouvoir mieux orienter mes recherches.
Pour le sujet, j'ai limité mes explications à 2 bases de données, mais mon code doit fonctionner pour un nombre non limité de bases de données.

J'ai peur de ne pas faire les bonnes affectations entre les transactions, les bases de données et les requêtes, ce que je fais, c'est chaque transaction est affectée à une unique base de données (une transaction pour la source et une pour la destination). Et chaque base de données possède sa transaction.
Exemple pour la source :

Code :

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

1
2
3
          ibTransactionSource.RemoveDatabases;
          ibTransactionSource.AddDatabase( ibSource.Database );
          ibSource.Database.AddTransaction( ibTransactionSource );

Si la base de données source est la même que la base de données destination, elle possède 2 transactions. C'est bien ainsi qu'il faut faire ?

Merci pour votre aide.

[WebPac]

Je me demande si cela ne vient pas du fait que je mets 2 transactions sur la même base de données, la première pour faire une requête du type SELECT et la seconde pour faire une requête du type INSERT.
Je pense que je dois continuer à utiliser la transaction pour faire l'INSERT, mais je me demande si je suis obligé d'utiliser une transaction pour faire le SELECT, je vais essayer de la supprimer pour voir si ça fonctionne ou pas.
En faisant ainsi, je me retrouve avec une transaction unique pour sur la base destination et la requête qui fait l'INSERT.

[WebPac]

En supprimant la transaction source, un truc bizarre est arrivé.
J'ai la transaction de ma requête source qui est la même que la transaction de la requête destination, ce sont des références sur la même instance de transaction.

C'est très bizarre, je vais donc revenir à 2 transactions et continuer à chercher quel peut être le problème.

[Rayek]

Si la transaction Select permet de renseigner la transaction Insert, il faut que cela soit fait dans une même transaction.
Car, qui te dit qu'entre ton Select et l'Insert quelqu'un ne modifiera pas un des enregistements ?

Sinon pour ton erreur du 1er message, je pense que tu dois faire un commit ou un rollback alors que tu n'as pas commencé de transaction. (c'est ce à quoi me fait penser ce message)

[WebPac]

A priori, il n'y a que mon programme qui peut accéder et modifier les enregistrements de la base de données destination.
Mis à part cela, je doute pouvoir faire les 2 requêtes dans la même transaction car la base de données source peut ne pas être de type Firebird et dans ce cas, j'utilise les composants dbXpress, TSQLConnection, TSQLQuery,...
Ainsi, je dois faire un code source et un code destination séparés.
D'ailleurs pour compliquer la tâche, la destination n'est pas forcément non plus du type Firebird, mais dans ce cas là, ça fonctionne, je ne demande qu'avec Firebird en destination.

En fait, j'ai le message d'erreur lorsque j'essaie d'ouvrir une requête du type SELECT.

En continuant dans mes recherches, je crois que cela vient du fait qu'avant toute manipulation, je réinitialise toutes les transactions de la base de données destination.
Je faisais une réinitialisation considérant que partir à plat puis faire les affectations était plus simple et plus propre, hors on dirait que ça pose problème.

[WebPac]

Ce que je ne comprends pas par exemple, si je fais :

Code :

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

1
2
3
ibTransactionDest.DefaultDatabase := DatabaseDest;
DatabaseDest.AddTransaction( ibTransactionDest );
ShowMessage( IntToStr( DatabaseDest.TransactionCount ) );

ou si je fais :

Code :

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

1
2
ibTransactionDest.DefaultDatabase := DatabaseDest;
ShowMessage( IntToStr( DatabaseDest.TransactionCount ) );

J'obtiens le même nombre : 2.
Finallement, on n'a pas besoin d'affecter les transactions dans les composants Database, suffit d'affecter les bases dans les composants Transaction ?

[WebPac]

Salut, j'ai trouvé l'origine de mon problème.
Lors de mon premier rappatriement, j'utilise une transaction pour la requête SELECT, à la fin je ferme la requête source mais je ne désactivais pas la transaction, elle était toujours active et toujours InTransaction.
J'utilisais cette transaction pour faire le second rappatriement et je ne pouvais pas ouvrir la seconde requête car elle utilisait une transaction toujours active.

Je ne comprends pas encore bien le fonctionnement de tout cela, lorsque j'ouvre une requête, ça active la transaction sans le demander explicitement, par contre, lorsque je ferme la requête, je dois explicitement fermer la transaction.
Mais l'important est que cela fonctionne.

[Cl@udius]

Salut

Je ne comprends pas encore bien le fonctionnement de tout cela, lorsque j'ouvre une requête, ça active la transaction sans le demander explicitement, par contre, lorsque je ferme la requête, je dois explicitement fermer la transaction.

C'est le fonctionnement par défaut des composants IBExpress.
A l'ouverture d'un DataSet la transaction reliée est implicitement démarrée. Ca c'est OK !

Pour la fermeture de la transaction, cela dépend de la valeur de AutoStopAction.
Si cette valeur est saNone, aucune action n'est entreprise et la transaction reste active.

Dans le cas contraire l'arrêt est implicite en suivant la valeur (saRollBack, saCommit, saRollBackRetaining ou saCommitRetaining).

Il est à noter que ceci se produit à la fermeture du dernier DataSet relié à cette transaction.

A noter également que la valeur de AutoStopAction doit obligatoirement être à saNone si un composant TIBSQL lui est relié, car ce composant transaction ne peut détecter si un TIBSQL est actif.

Dernière remarque: Attention à l'utilisation des composants IBX avec Firebird, surtout si tu utilises FB2. Ces composants ne sont plus vraiment compatibles.

@+ Claudius

[WebPac]

Merci pour ces précisions.

Dernière remarque: Attention à l'utilisation des composants IBX avec Firebird, surtout si tu utilises FB2. Ces composants ne sont plus vraiment compatibles.

Ca c'est très embêtant car je comptais migrer progressivement les utilisateurs de Firebird 1.5 vers Firebird 2.0.

Plus vraiment compatible veut quand même dire compatible ou veut dire il vaut mieux oublier la cohabitation ?
N'y-a-t-il pas de mise à jour des composants pour FB 2 ?

[WebPac]

En fait, je n'utilise Firebird que pour créer des tables, insérer des données, créer des index, supprimer les tables et les index et faire des requêtes dessus.
Je n'utilise rien de particulier spécifique à Firebird, j'espère qu'IBX ne pose pas de problèmes pour ce que je fais.