[OAppli][forms 6i] Statut des enregistrements après POST

[Magnus]

Bonjour,

Je travaille sur Oracle Application 11.5.9 avec forms 6i.
Dans un bloc multiligne basé sur une table, j'ai besoin de faire un appel à la procédure interne POST afin de lancer un algorithme spécifique.

L'ennui que je rencontre est qu'après un appel à POST, tous les enregistrements ont le statut QUERY donc je n'ai plus de moyen de savoir quels sont ceux qui existent en base de ceux qui n'existent pas.
Or, je souhaiterais autoriser l'utilisateur à supprimer uniquement les enregistrements qui n'existent pas en base ; ce qui m'est impossible dans l'état actuel.

Comment palier à cette conséquence assez facheuse (en stockant le ROWID et en basant mon bloc sur non plus une table mais une clause FROM ?).
Merci d'avance.

PS : je découvre Oracle Appli donc je ne peux pas me prononcer sur les spécificités de cette "couche".

[salim11]

Salut Magnus,

Il n'y pas mieux que la solution de plaineR, créer une table temporaire gérée par le pre-insert.

S'il existe dans ta table temporaire alors la suppression est permise sinon la suppression est interdite.

[Magnus]

Salut Salim,

Hum... je comprends l'idée mais malheureusement dans les structures informatiques "trop organisées / méthodologiques" on n'a généralement pas le droit de créer une table temporaire sans le justifier et que ce soit la SEULE solution...

Bref, la solution que je retiens actuellement - mais je suis preneur de toute amélioration - procède de la manière suivante :
- détection des lignes qui posent problème lors du lancement de l'algorithme spécifique après un appel à POST
- suppression sans condition de ces lignes non réellement insérées dans la base de données par un appel à CLEAR_FORM(NO_VALIDATE) et affichage d'un message d'erreur.

Au niveau de l'ergonomie, je te l'accorde, c'est très moyen.
Cependant, face :
- à l'incohérence de la consultation de :SYSTEM.RECORD_STATUS après un appel à POST
- à la désactivation automatique des lignes existantes en base par Oracle Application (?)
- au fait que RAISE FORM_TRIGGER_FAILURE n'est pas systématiquement bloquant
- ...
je trouve ma solution pas si mal

Merci de ton aide.

[salim11]

Salut Magnus,

Il faut toujours trouver une solution avec les moyens de bord.

Bonne chance.