Discussion :

[Stoune]

Bonjour,

J'ai un petit probleme avec un de mes curseurs.

Je crée mon curseur de la façon suivante:

CURSOR TOTO IS (SELECT Blablabla);

Tout va bien, le curseur est crée et la boucle FOR ...LOOP marche très bien aussi.

Je traite ensuite chaque row du curseur et selon les valeurs, j'execute soit un UPDATE soit un INSERT. (INSERT executé si colonne 5 de mon curseur est NULL).

Premiere row du cursor, colonne 5 NULL, donc, je fait un INSERT, le nouveau record est bien créé correctement, et lors de sa création, un trigger s'execute et met à jour une autre valeur.
Valeur qui est dans mon curseur, dans le troisieme record.

Quand mon curseur arrive sur le troisieme record, il verifie la valeur de la colonne 5 pour savoir s'il va faire un UPDATE (colonne non NULL) ou un INSERT (colonne NULL).
Et ma procedure fait un INSERT car elle voit la valeur NULL dans le curseur, alors que mon INSERT executer pour le row 1 du cursor a déclenché un trigger qui a mis a jour l'information.
C'est à dire que si j'avais re-créer mon curseur a ce moment la, la colonne 5 de la ligne 3 ne serait PLUS NULL.

D'ou ma question:
Comment faire pour que mon cursor soit dynamiquement mis a jour quand je passe au row suivant?

J'espère que la description du problème est claire, ce n'est pas très simple a expliquer...

Merci d'avance pour votre aide...

[dragon74]

Je suis tenté de dire que tu devras fermer et puis réouvrir le curseur. Peut-être qu'avec un fetch, ca marchera mais j'ai un doute.Voici un peu de doc venant d'Oracle (en anglais, désolé):

Opening a Cursor
Opening the cursor executes the query and identifies the result set, which consists of all rows that meet the query search criteria.

The query can reference PL/SQL variables within its scope. Any variables in the query are evaluated only when the cursor is opened. In Example 6-11, each retrieved salary is multiplied by 2, even though factor is incremented after every fetch.

Example 6-11 Referencing PL/SQL Variables Within Its Scope

DECLARE
my_sal employees.salary%TYPE;
my_job employees.job_id%TYPE;
factor INTEGER := 2;
CURSOR c1 IS
SELECT factor*salary FROM employees WHERE job_id = my_job;
BEGIN
OPEN c1; -- factor initially equals 2
LOOP
FETCH c1 INTO my_sal;
EXIT WHEN c1%NOTFOUND;
factor := factor + 1; -- does not affect FETCH
END LOOP;
CLOSe c1;
END;
/

[Stoune]

Bonjour et merci d'avoir répondu.

Le problème à mon avis, c'est que si je ferme le curseur et le réouvre, je vais recommencer l'execution depuis mon premier row, ce que je ne veux pas...

Après discussion avec des collègues ici au boulot, j'imagine une solution du genre:
CURSOR C1 is (SELECT un_id FROM ma_table)
FOR CUR1 IN C1
LOOP
CURSOR C2 (id IN number) IS SELECT tout_les_champs_utiles FROM ma_table where ID=id);
OPEN C2(C1.un_id);
FETCH C2 in C2_rec;
--traitement
CLOSE C2;
END LOOP

De cette façon, le premier cursor ne contient que les id uniques qui me permettent d'ouvrir C2 (qui ne contiendra qu'un enregistrement).
C2 est ouvert et fermé a chaque fois, donc quand il est ouvert, il contient les valeurs "à jour", et je ne recommence pas a chaque fois au début de mon curseur.

Ce serait une bonne solution?

J'ai aussi entendu parlé de BIND, mais la j'ai pas compris grand chose...

Je teste ce que j'ai expliqué au dessus et je donne un feedback si ca marche...

Merci encore.

[orafrance]

à mon avis faut carrêment revoir le modèle là... parce que c'est pas très net ton histoire

[plaineR]

Si tu ne traites qu'une ligne autant remplacer le curseur C2 par un select into.

[dragon74]

Tu peux nous expliquer dans les grandes lignes ce que tu essayes de faire car j'ai aussi du mal à comprendre le but final suivant ton explication.

Comme dit orafrance, j'ai du mal à comprendre la raison de cette manipulation

[Stoune]

Ok, ca va pas etre très facile, mais on va essayer...

Je travail sur un gros systeme qui permet la gestion des effets secondaires des medicaments de ma boite (grosse pharma company).

Dans ce systeme, on peut importer/exporter des données au format xml (format standardisé international).

Pour un couple donné de médicament/effet secondaire, on entre une valeur appelée causalité (est ce que l'effet secondaire est liée a la prise du medoc ou pas).
Cette causalité peut avoir plusieurs sources differentes (celle du reporter de l'effet secondaire, celle de la company, autre).

Bon, j'espère que jusque la ca va.

Donc, on a une table PRODUCT (id, seq_product), une table REACT (id, seq_react) et une table PRODUCT_AE_ASSOCIATION (id, SEQ_AE_ASSOCIATION, SEQ_PRODUCT, SEQ_REACT).
Donc par exemple si j'ai un rapport d'effet secondaire d'un gars qui prend deux medocs et qu'a fait trois AE (Adverse Event, ie effet secondaire)
J'aurais 6 records dans PRODUCT_AE_ASSOCIATION, et les colonnes CAUSALITY_COMPANY et CAUSALITY_REPORTER remplies avec les-dites causalités.

Probleme: Quand on export ou import en xml (donc au format standardisé par les régions ICH, si le modèle est a revoir, faut se plaindre a l'EMEA et a la FDA, donc on peut courrir), le format pour donner la relation de causalité est fait de telle facon qu'on a un tag pour la valeur de la causalité elle meme (Possible/Probable/Not related, etc...) et un tag pour la source de la causalité (reporter/company/etc).

Donc, on passe par une table suplémentaire qui est au format suivant:
id, seq_ae_association, seq_product, Seq_react, Source (donc company/reporter), Value(possible/probable...).

SAUF QUE, les tags dans le xml sont pour la source et la value, des free texts. Donc le programme d'import en standard va pas forcément correctement coder la source ou la value dans la table d'association.

Et la, ma procedure commence:
Donc je récupère les infos du xml importé dans la table temporaire, qui est donc comme je l'ai dit au format:
id, seq_ae_association, seq_product, seq_react, source, value.
1, null , 2, 2, REPORTER, Possible
1, null , 2, 2, COMPANY, Probable.

C'est a dire deux record qui doivent au final tenir dans un, vu que dans ma table PRODUCT_AE_ASSOCIATION, j'ai des colonnes CAUSALITY_COMPANY, CAUSALITY_REPORTER.

J'ouvre mon cureur sur tout ce que j'ai dans la table temporaire pour créer mes nouveaux records.
Je prends mon premier records, je vois que seq_ae_association est null, donc ca veut dire que j'ai pas encore de record dans PRODUCT_AE_ASSOCIATION.
Je créé ce record avec mon script, et je passe au row suivant.
Sauf que si vous avez suivi, je suis toujours au meme couple produit/reaction, donc je NE DEVRAIS PAS recréer un nouveau record.
Mais mon cursor ne se mettant pas a jour tout seul, je vois que la colonne est null, mon script est bete et mechant, et il me créé un doublon...

Alors vous me direz, ok le format xml est standardisé et tu peux rien changer a ca, change ton systeme.
Et d'un coté, c'est pas faux que le système pourrait etre un peu mieux, mais c'est aussi du gros système proprio qui coute beaucoup de dollars avec plein de zéro et qu'est en gros leader de ce domaine dans les pharmas company, donc on peut pas changer grand chose...

Je sais pas si c'est beaucoup plus clair pour vous maintenant, j'ai fait au mieux pour décrire correctement la chose...
J'ai tourné et retourné le problème dans tout les sens et je pense que je vais utiliser ma solution décrite plus haut.

PS: Pour le remplacement de C2 par un SELECT INTO, ca marchera effectivement aussi, c'était plus par flemme d'avoir a déclarer 8 variables dans lesquels fetcher les valeurs du select, mais ca revient effectivement au meme.