Discussion :

[pdelorme]

Bonjour,

J'effectue un chargement d'un fichier avec tos dans une base postgres.
Ce chargement insert d'abord dans une table puis dans une autre.
Les données insérées dans ma deuxième table sont liées aux données insérées dans la première (bref une association toute bête)
Pour ce faire :
1/ j'insère dans ma première table (tPostgresqlOutput)
2/ je recherche l'id de la donnée insérée par un select (tPostgresqlInput)
3/ je jointure l'id a mon flux de données (tMap)
4/ j'insert dans ma deuxième table avec l'id qui va bien.
A notre que je réutilise la même connexion pour les 4 étapes. Ma connexion est en autocommit.

Mon problème et que je n'arrive pas a résoudre l'id en étape 2 car la donnée insérée n'est pas trouvée. Du coup je ne peux insérer dans ma deuxième table.
Par contre si je relance mon job, l'insertion 4 marche a la deuxième itération.

En clair, le sélect ne vois pas l'insert qui viens juste d'être insèré. comme si cela était fait dans des connexions différentes non commitées.

Cette problématique étant Classique, je passe sans doute a coté d'un truc évident. Cela serait sans doute plus simple de récupérer l'id directement a l'insert mais je n'ai pas trouve comment faire cela.

Merci de vos eclairages

[NicolasTT]

Bonjour,

Nous avons eu la même problématique, cf.
http://www.developpez.net/forums/d10...uto-increment/

Nous n'avons pas trouvé de meilleur moyen que la procédure stockée.

Je serai très intéressé par de meilleures réponses.

[pdelorme]

Mon problème est un peut différent dans le sens que j'arrive "en théorie" a récupérer l'id du row insèré (sans passer par tLastInsertedId mais en recherchant l'id dans l'étape suivante de mon flux... ) le problème est qu'il semble que le sélect ne vois pas l'insert qui viens d'avoir lieu.

En clair si j'insert X dans la table A et que je sélect id de la table A where X immédiatement apres, la ligne n'est pas trouvée. Par contre si je fait sélect id de A where X dans un autre job, je trouve ma ligne...

[pdelorme]

En fait, il semble que tous les tPosgresqlInput soient chargés au démarrage de mon flux.... du coup les données insérées dans mon process ne sont pas vu dans mes maps...
comme on le vois sur le screenshot, la table parts est chargé avant que TMap_7 n'ai eu le loisir d'insérer dans la table parts

La question est : comment faire pour que les tPostgresInput ne soient chargé que lors de l'execution du tMap_3

[CyberChouan]

Un lien de type "onSubjobOK" entre l'insertion et la lecture devrait garantir que le second tPostgreSQLInput sera bien exécuté après l'insertion de la ligne, et donc qu'il récupérera le bon ID.