Discussion :

[Kathy.38]

Bonjour à tous,

Je fais face à un problème pour lequel je ne trouve pas le bon angle de résolution… (très embêtée)

Je dois traiter une table d’article (ARTICLE) en trouvant (entre autres choses) pour chacun d’eux la date du dernier mouvement de stock.
(il s'agit d'une reprise Article, donc un record à créer pour un record lu).

J’ai donc une table de mouvement (HISTO) sur laquelle je fais une jointure pour trouver les mvts de chaque article.

La clause ORDER BY me permet de trier ces mvts du plus récent au plus ancien, jusque là, ça va.

Mon souci est que je ne dois lire, pour chaque ARTICLE, que le premier mvt HISTO (le plus récent, donc, une fois triés par ordre décroissant), pour en tirer une info qui me permettra de lire d’autres tables.
(tous les autres records HISTO de l'article traité sont ignorés)

Je serais en ABAP, la clause "UP TO 1 ROWS" serait exactement prévue pour ça... mais je n'en dispose pas dans le panneau de gestion de ma query. Ni les onglets "Avancé" , "Rechercher" ou "GROUP BY" ne semblent d'aucun secours...

J’ai essayé d’utiliser des fonctions comme gen_row_num(), sans succès…

Comment procéder ? Quelqu'un a une idée ???

Merci d'avance à tous... Et passez de bonnes fêtes !

[mapk0]

Bonjour Kathy.378

Tu as presque la solution, il suffit d'utiliser la fonction gen_row_num_by_group() et pas gen_row_num() :

Tu tri d’abord tes données par articles puis par mouvement avec order by pour avoir un truc du genre
Article | mouvement
A | date A1
A | date A2
A | date A3
B | date B1
B | date B2

Ensuite tu ajoute une colonne avec la fonction gen_row_num_by_group( Article) <- il faut mettre le groupe trier sinon marche pas
Cette fonction génère une séquence qui est réinitialisée à chaque changement de valeur du groupe.

Tu aura donc:

Article | mouvement | seq
A | date A1 | 1
A | date A2 | 2
A | date A3 | 3
B | date B1 | 1
B | date B2 | 2

Puis dans une autre query tu filtre pour ne garder que les séquences à 1.

On peux aussi faire la même chose avec un group by est un max() min() pour trouver le premier mouvement,la diference est si il y a des données de détails à récupérer du mouvement, avec un group by, il faudrait refaire une jointure avec la table HISTO sur la valeur max()=...

Voilà, j’espère être suffisamment clair!

[Kathy.38]

Voilà, je reviens après une pause de Noël... !

Merci pour ta réponse, je vais essayer de coder ça... Après le nouveau petit défi dont je viens d'hériter ce matin !

Je reviens bientôt pour te faire part de la progression du sujet, merci à toi !

Et bonnes fêtes à tous !

[Kathy.38]

OK, c'est parfait, ça fonctionne !

En revanche... en revanche, et ce n'est pas la première fois que ça m'arrive : ça fonctionne une fois, puis, plus du tout !

La requête s'arrête sans message d'erreur... toujours sur la même information :

" Flux de données <DF_EQUI_HISTO> utilisant le cache PAGINABLE avec un pool de tampons de <3503 Mo>. "

Puis, plus rien. Aucun message dans le suivi, rien de rien.

Si j'essaie de relancer avec un jeu d'essai réduit, même punition : la table résultat n'est pas mise à jour...

J'ai écumé le net, les vidéos de formation, les manuels utilisateurs, les forums (anglophones), sans résultat, je suis désespérée !

Une énième recherche sur internet sur ce symptôme m’a aiguillé sur deux pistes :
- Sur un problème ressemblant, il est pointé un problème de version ( LA )
- Autre piste : un paramétrage du serveur ( ICI )

Mais sans que je puisse faire qq chose, je ne suis pas admin du serveur...

Est-ce que je dois ouvrir un nouveau sujet pour ça ?

Bonjour Kathy.378

Tu as presque la solution, il suffit d'utiliser la fonction gen_row_num_by_group() et pas gen_row_num() :

Tu tri d’abord tes données par articles puis par mouvement avec order by pour avoir un truc du genre
Article | mouvement
A | date A1
A | date A2
A | date A3
B | date B1
B | date B2

Ensuite tu ajoute une colonne avec la fonction gen_row_num_by_group( Article) <- il faut mettre le groupe trier sinon marche pas
Cette fonction génère une séquence qui est réinitialisée à chaque changement de valeur du groupe.

Tu aura donc:

Article | mouvement | seq
A | date A1 | 1
A | date A2 | 2
A | date A3 | 3
B | date B1 | 1
B | date B2 | 2

Puis dans une autre query tu filtre pour ne garder que les séquences à 1.

On peux aussi faire la même chose avec un group by est un max() min() pour trouver le premier mouvement,la diference est si il y a des données de détails à récupérer du mouvement, avec un group by, il faudrait refaire une jointure avec la table HISTO sur la valeur max()=...

Voilà, j’espère être suffisamment clair!

[mapk0]

Hum difficile de t'apporter une réponse sur ce genre de problème sans plus détail, en gros le dataflow se lance puis attend, voici quelques pistes:

- Tu parle de mise à jour / et ça marche la 1ere exécution puis ça se bloque celles d'après. Avec ce que tu dis ça ressemble fortement à un blocage au niveau de la base de donnée plutôt qu'a un bug:
1ere chose, lors du problème regarder les sessions et requêtes en cours sur la BDD, et chercher les locks. Ça peux être une requête qui n'a pas aboutie mais qui tourne toujours et donc qui bloque les requêtes suivantes. Ça peut arriver suite à un plantage ou après avoir killer un job, un commit non fait etc. Tu utilise quelle base?

- Regarde en plus du suivi, la partie monitor (surveillance) pour voir si le nombre de lignes traitées bouge et donc si le job tourne même très lentement (mettre un paramètre "monitor sample rate" suffisamment faible pour ne pas attendre trop entre chaque actualisation)

- Si non: regarder si le job bodi tourne toujours sur le serveur (process al_engine) , dans ce cas il attend quelque chose (réponse de la bdd?) sinon il a planté sans message et là ce sera plus galère à trouver, il faudra chercher dans les logs du serveur par exemple.

- regarde aussi s'il n'y a pas des anciens process bodi qui tournent encore et bloquerai le traitement.

Identifier à quel moment exactement à lieu le blocage:
- Essayer en mode débug voir si ça marche et sinon où il en est lors du blocage.
- Essayer de mettre des filtres au fur et à mesure dans les query de ton dataflow pour faire du pas à pas
Par exemple pour s’arrêter juste avant de modifier la table finale, mettre une condition where 0=1 dans une query avant la table, ainsi il y aura 0 lignes modifiées. Si le DF se termine, ça voudra bien dire que c'est lors de la mise à jour en base qu'il y a un blocage.

[Kathy.38]

Merci pour tes pistes, je vais regarder ça de plus près...

Et dès que j'ai du nouveau (en bien ou en mal)... "Je reviendrai" ! (comme disait l'autre)

[Kathy.38]

Merci pour tes pistes, je vais regarder ça de plus près...

Et dès que j'ai du nouveau (en bien ou en mal)... "Je reviendrai" ! (comme disait l'autre)

Le problème est "simple" : si je n'ai pas de message d'erreur, c'est que le job ne démarre pas ! Durée : 0s !



Rien de plus dans le suivi, fichier erreur vide (évidemment, puisqu'il ne fait rien...)

Pour info : j'ai fermé ma session, puis supprimé tout l'historique des jobs... Rien ne change. J'ai deux Jobs qui présentent ce symptôme, et tous les autres qui tournent correctement !...

[mapk0]

Ton résonnement n'est pas vraiment bon. La durée ne s'actualise pas tant que le Job n'est pas fini, il peut très bien être en attente sans avoir planté. Ou avoir planté sans message après plusieurs heures de traitements...
Tu as regardée le reste? Tu n'a rien dans les pages "suivi" et "surveillance" ?

Tu disais avoir le message: " Flux de données <DF_EQUI_HISTO> utilisant le cache PAGINABLE avec un pool de tampons de <3503 Mo>. "
Donc tu as bien un dataflow qui a démarré!

Ah mon avis tu ne peux pas faire grand chose avec la console de gestion, ça ne permet pas de tuer les process fantômes, tu peux juste killer un job, mais ça ne va pas toujours tuer les sessions en BDD. Et rien à voir avec la session sous la console (la fermer ou supprimé l'historique des jobs n'a aucune action sur les jobs qui tournent) : Il faut que tu aille voir sur la base de donnée!

Sinon que fait le DF F_EQUI_HISTO ?

[Kathy.38]

Victoire !

Alors... Un peu par hasard, je l'avoue (et aussi en désespoir de cause, un peu), j'ai fait la modif suivante : j'ai importé ma table cible (nommée T_ADR_FRN ci-dessous).

(c'est-à-dire que je l'ai passée de "modèles de table" à "tables")



Et... tin-din ! ça fonctionne ! (soulagée)

Maintenant, pour avoir l'explication du pourquoi du comment... Prt...

[mapk0]

Bon tant mieux! Tu as surement trouvé une solution pour contourner le problème.

Je reste sur mon intuition de départ, problème de verrou sur la Base de donnée.
Peut être que tu n'as pas accès à cette partie ou que tu ne maitrise pas bien les BDD, dans ce cas tu aurais pu voir avec ton DBA.

En effet, ce que tu as fait c'est de passer d'une table temporaire à une table définitive.

En gros quand tu utilise une table temporaire avec BODS, la 1ere chose que fait BODI et d'envoyer une requête pour supprimer la table , puis une autre pour la recréer.
Pour un peu que la table soit occupée, la requête de suppression sera bloquée.

En transformant la définition en "table", BODS ne cherche plus à faire la requête de suppression/recréation. Attention si tu fais de l'insertion, ta table ne sera plus vidée si tu ne le précise pas dans les options de la table CIBLE.

Voila pour une explication possible...

[Kathy.38]

En tout cas, merci d'avoir été dispo... Dans ces occasions, c'est appréciable, on se sent moins seule !