Erreur dans 1 exec Block

Bonjour,

J'ai 1 classique besoin de transfert de données entre 2 bases, les tables source & cible se ressemblent, mais la normalisation est passée par là :lol:
source:

Code:

---

1 2 3 4 5

CREATE TABLE AFFECTATION ( AFF_ANNEE INTEGER NOT NULL, ATE_REF VARCHAR(10) NOT NULL, OUV_NUMSS NUMSS NOT NULL );

---

Cible:

Code:

---

1 2 3 4 5

CREATE TABLE AFFECTATION ( AFF_ANNEE INTEGER NOT NULL, OUV_CLE INTEGER NOT NULL, ATE_CLE INTEGER NOT NULL );

---

Je tente ce code (largement inspiré d'échanges sur le forum en mode singe voit-singe fait):

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

SET TERM !; EXECUTE BLOCK AS DECLARE VARIABLE C1 int ; DECLARE VARIABLE C2 varchar(10); DECLARE VARIABLE C3 char(13); DECLARE VARIABLE C4 int ; DECLARE VARIABLE C5 int ; BEGIN FOR EXECUTE STATEMENT 'SELECT AFF_ANNEE,ATE_REF,OUV_NUMSS FROM AFFECTATION' ON EXTERNAL 'localhost/3050:C:\FB2.17\GESTCAT2-1.FDB' AS USER 'SYSDBA' PASSWORD 'masterkey' INTO :C1,:C2,:C3; DO select OUV_CLE from OUVRIER where OUV_NUMSS=:C3 INTO :C4 select ATE_CLE FROM ATELIER WHERE ATE_REF_INTERNE=:C2 INTO :C5 INSERT INTO AFFECTATION VALUES(:c1,:c4,:c5); END! SET TERM ;!

---

et sous Flamerobin, ça tousse

Citation:

---

Error: *** IBPP::SQLException ***
Context: Statement::Prepare(
EXECUTE BLOCK
AS
DECLARE VARIABLE C1 int ;
DECLARE VARIABLE C2 varchar(10);
DECLARE VARIABLE C3 char(13);
DECLARE VARIABLE C4 int ;
DECLARE VARIABLE C5 int ;
BEGIN
FOR EXECUTE STATEMENT 'SELECT AFF_ANNEE,ATE_REF,OUV_NUMSS FROM AFFECTATION'
ON EXTERNAL 'localhost/3050:C:\FB2.17\GESTCAT2-1.FDB'
AS USER 'SYSDBA' PASSWORD 'masterkey'
INTO :C1,:C2,:C3;
DO
select OUV_CLE from OUVRIER where OUV_NUMSS=:C3 INTO :C4
select ATE_CLE FROM ATELIER WHERE ATE_REF_INTERNE=:C2 INTO :C5
INSERT INTO AFFECTATION VALUES(:c1,:c4,:c5);
END )
Message: isc_dsql_prepare failed

SQL Message : -104
Invalid token

Engine Code : 335544569
Engine Message :
Dynamic SQL Error
SQL error code = -104
Token unknown - line 11, column 8
ON

---

La ligne 11 étant le ON EXTERNAL ...

Une idée? Est-ce lié à la version 2.1 utilisée?

Merci de vos retours.

Bonjour,

ON EXTERNAL a été ajouté avec la version 2.5 https://firebirdsql.org/refdocs/lang...at-on-external

Code:

---

1 2 3 4 5

STMT= 'SELECT AFF_ANNEE,ATE_REF,OUV_NUMSS FROM AFFECTATION'; FOR EXECUTE STATEMENT STMT ON EXTERNAL 'alias' INTO :C1,:C2,:C3;

---

Je préfère nettement l'utilisation d'une variable pour la clause, des alias et, si les accès sont les mêmes, pas besoin de déclarer les user et password

La solution, créer une table OLDAFFECTATION, insérer les données de la vieille base et utiliser un bon vieux FOR SELECT :roll:
Le tout doit pouvoir se faire dans un bloc, même la suppression de OLDAFECTATION.
les GLOBAL TEMPORARY TABLE existent déjà en FB 2.1 (Global Temporary Tables (GTTs) Added in: 2.1) donc en utilisant ce truc à la création de la table on se passe de la suppression

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

SET TERM !; EXECUTE BLOCK AS DECLARE VARIABLE C1 int ; DECLARE VARIABLE C2 varchar(10); DECLARE VARIABLE C3 char(13); DECLARE VARIABLE C4 int ; DECLARE VARIABLE C5 int ; BEGIN CREATE global temporary TABLE OLDAFFECTATION ( AFF_ANNEE INTEGER NOT NULL, ATE_REF VARCHAR(10) NOT NULL, OUV_NUMSS NUMSS NOT NULL ); -- INSERTs à récupérer dans la 'vieille base' merci flamerobin, changer AFFECTATION généré par OLDAFFECTATION FOR SELECT AFF_ANNEE,ATE_REF,OUV_NUMSS FROM OLDAFFECTATION INTO :C1,:C2,:C3; DO select OUV_CLE from OUVRIER where OUV_NUMSS=:C3 INTO :C4 select ATE_CLE FROM ATELIER WHERE ATE_REF_INTERNE=:C2 INTO :C5 INSERT INTO AFFECTATION VALUES(:c1,:c4,:c5); END! SET TERM ;!

---

Bonjour Sergio,

Merci pour ton retour rapide. Il faudra que je me décide à au moins passer en 2.5:mouarf:

Bon, la séquence que tu as eu la gentillesse de fournir bloque sur le CREATE de la GTT:

Citation:

---

Token unknown - line 10, column 1
CREATE

---

et je n'ai rien vu d'anormal par rapport à la doc (2.1) 8O

Par ailleurs, les INSERTs produits par Flamerobin font ressortir AFF_ANNEE sous la forme

Code:

---

'2005'

---

alors que c'est de l'integer.
Un "change all" (merci NotePad++) rectifie tout ça, mais c'est curieux.

J'ai opté par la création en non GTT de 'OLDAFFECTATION' pour y insérer les lignes.

Ensuite, encore qq soucis...
Au premier essai, je n'avais qu'une ligne 8O en fait, il manquait 1 BEGIN/END (le FOR SELECT devait boucler sur le 1er select OUV_CLE)
Voici la version finale:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

SET TERM !; EXECUTE BLOCK AS DECLARE VARIABLE C1 int ; DECLARE VARIABLE C2 varchar(10); DECLARE VARIABLE C3 char(13); DECLARE VARIABLE C4 int ; DECLARE VARIABLE C5 int ; BEGIN FOR SELECT AFF_ANNEE,ATE_REF,OUV_NUMSS FROM OLDAFFECTATION INTO :C1,:C2,:C3 DO BEGIN select OUV_CLE from OUVRIER where OUV_NUMSS=:C3 INTO :C4 ; select ATE_CLE FROM ATELIER WHERE ATE_REF_INTERNE=:C2 INTO :C5 ; INSERT INTO AFFECTATION VALUES(:c1,:c4,:c5); END END! SET TERM ;!

---

:oops: désolé pour le manque du begin/end, le code proposé avait été écrit à la volée plus pour donner une idée que par souci d'exactitude.

La table OLDAFFECTATION, tu l'as créé hors du bloc donc elle eut pu être en GTT en

Code:

---

ON COMMIT PRESERVE ROWS

---

pour garder les INSERTs que tu as dû faire, eux aussi, à part, mais comme je présume que par la suite, elle est supprimée, cela importe peu.

Citation:

---

Par ailleurs, les INSERTs produits par Flamerobin font ressortir AFF_ANNEE sous la forme '2005'
alors que c'est de l'integer.

---

Cela n'importe pas, d'expérience, ça fonctionne quand même ;)

Citation:

---

désolé pour le manque du begin/end, le code proposé avait été écrit à la volée plus pour donner une idée que par souci d'exactitude.

---

Je n'ai pas de souci par rapport à ça. C'est bien l'esprit du forum que de donner des pistes :plusser:, ne plus être Modo ne m'a pas fait glisser dans le "faites mes devoirs/mon boulot" :lol:.
D'ailleurs, sans attendre un retour, j'ai réfléchi et contourné la difficulté...

Ceci dit, par rapport à la GTT, peux-tu préciser l'endroit où doit se faire sa création ? Pour mémoire, dans la version que tu avais présentée, ça coinçait, c'est ce qui m'a conduit à une table persistante.

Et pour le

Code:

---

ON COMMIT PRESERVE ROWS

---

j'ai bien vu cette option dans la doc.
Cependant je m'interroge sur le contexte d'emploi :roll: et du coup sur le caractère temporary de la table.

Attention, le ON COMMIT PRESERVE ROWS permet de vider la table en fin de session, mais une GTT ne s'auto-supprime pas.

[Edit] Quelques explications supplémentaires fournies d'abord en MP
Par exemple si tu as une GTT "normale" (sous-entendu ON COMMIT DELETE ROWS)
si pendant ta session flamerobin , tu écris

Code:

---

1 2 3 4 5

INSERT INTO MAGTT(..) VALUES (..); INSERT INTO MAGTT(..) VALUES (..); INSERT INTO MAGTT(..) VALUES (..); COMMIT; SELECT * FROM MAGTT;

---

Tu auras un résultat vide

a contrario si tu as un GTT ON COMMIT PRESERVE ROWS ton résultat contiendra les 3 lignes

Si maintenant, tu te déconnectes/reconnectes de la base alors un SELECT * FROM MAGTT; sera vide.

Cependant, dans les deux cas, la structure de la GTT reste dans la structure de la BDD. Pratique pour l'utilisation de tables temporaires qu'au temps du BDE, on pouvait créer comme tables paradox