[forms 6i] suppression "automatique" dans un bloc multi-enregistrements [Résolu]

[Magnus]

Bonjour

Je constate que dans certains écrans contenant un bloc multi-enregistrements, lorsque l'on créée un enregistrement dans lequel on ne saisit rien et que l'on quitte cet enregistrement alors :
1/ l'enregistrement est automatiquement supprimé (cas des blocs base table ?)
2/ l'enregistrement est laissé tel quel et un appel à DO_KEY('CLEAR_RECORD') n'a aucun effet (aucune suppression, ni message d'erreur mais comme c'est une procédure restreinte je ne pense pas que ce soit une alternative qui puisse répondre à ce problème).

Ma question : pour un bloc non base table, savez-vous comment supprimer automatiquement un enregistrement dans lequel aucune donnée n'a été saisie ?

Cordialement,
Magnus

[Magnus]

Ma supposition est fausse (bloc base table ou non) : pour des raisons extérieures à ce post, j'ai du modifier certains blocs afin qu'ils soient base table.
Résultat, toutes les propriétés des blocs en question sont identiques à celles d'autres bloc issus d'écrans dont le dernier record est systématiquement supprimé lorsque rien n'est saisi.

Pourtant, rien à faire : dans l'écran actuel, le dernier record n'est pas supprimé automatiquement alors que je peux le supprimer via du code associé à un bouton (i.e. en invoquant DELETE_RECORD).

Personne pour me filer un coup de pouce ?

[plaineR]

Je ne comprends pas trop ce que tu appelles suppression automatique. Jette un oeil au statut de ton dernier enregistrement, s'il n'est pas new, c'est qu'il y a un problème (ou justement que je n'ai pas compris ta question ).

[Magnus]

Envoyé par plaineR

Je ne comprends pas trop ce que tu appelles suppression automatique.

Dans un bloc multi-enregistrements, quand j'appuiye sur la flêche du bas je "descends" à l'enregistrement suivant (NEXT_RECORD) et s'il n'existe pas alors il est créé en même temps (implicitement par NEXT_RECORD).
Lors de ce déplacement le compteur d'enregistrements situé dans la barre de message (est-ce bien ce nom ?) se met à jour :
x/total enregistrements => x/total enregistrements + 1

Dans d'autres écrans ayant des blocs multi-enregistrements, le fait de "remonter" en appuyant sur la flêche du haut, met à jour ce compteur d'enregistrements :
- si aucune donnée n'a été saisie alors j'en déduis que l'enregistrement a été supprimé parce que le compteur d'enregistrements revient à : x/total enregistrements
- si l'utilisateur a saisi des données alors seul le numérateur du compteur est mis à jour : x/total enregistrements + 1

Mes explications doivent être encore plus confuses mais je ne vois pas trop comment expliquer : avec des captures d'écrans ce serait mieux ?

[McM]

Non, c'est clair : Quand tu crées un second enregistrement avec forms et qu'aucun champ basé ou modifiable (ça je sais pas, faudrait tester) n'est mis à jour, si tu remontes, la ligne est considérée comme non créée et forms la supprime

[plaineR]

Comme je te le disais dans mon précédent post, c'est que le record status du dernier enregistrement a du être modifié (de NEW il est passé à INSERT).
Tu as du modifier un champs (même non basé) de ton block dans un trigger style when-new-record-instance.

[Magnus]

Merci à vous 2 de vos participations.

Désolé, j'avais dû laisser ce programme de côté pendant quelques temps pour passer à autre chose

J'ai une information qui a peut être son importance : dans le bloc il existe 2 zones non base table de type "calculé".
Peut être que la suppression automatique est inhibiée à cause de cette 2 zones ?

plaineR >> comment je peux tester le status du dernier enregistrement (il faut que je me déplace éventuellement parmi les enregistrements donc je ne pourrai pas dans les triggers dont les procédures restreintes sont interdites) ?

D'autre part, en y réfléchissant bien, les blocs pour lesquels le dernier enregistrement est supprimé automatiquement quand il est vide peuvent avoir des items non base table mais il s'agit d'éléments affichés et non d'éléments textes.

[plaineR]

Envoyé par Magnus

plaineR >> comment je peux tester le status du dernier enregistrement (il faut que je me déplace éventuellement parmi les enregistrements donc je ne pourrai pas dans les triggers dont les procédures restreintes sont interdites) ?

Dans le trigger when-new-record instance par exemple :

Code :

1
2
3
IF :system.last_record = 'TRUE' then
	message (:system.record_status);
end IF;

et puis tu te déplaces sur le nouvel enregistrement et tu regardes quel est son statut. Si c'est new, c'est OK, sinon c'est de là que vient ton problème

[EDIT]Je ne pense pas que cela vienne des items calculés, il me semble qu'ils ne changent pas le statut de l'enregistrement[/EDIT]

[Magnus]

Le status est bien : NEW

Cela en devient complètement folklorique : habituellement je ne peux créer les enregistrements que un par un (la touche Pg Down ne fait rien si l'enregistrement courant est vide et la touche Pg Up le supprime dans ce cas avant d'éventuellement remonter au précédent si ce n'est pas le 1er enregistrement).
De plus, je viens de m'apercevoir qu'avec la souris je peux créer des enregistrements vides "où je veux" (i.e. en cliquant sur la 6ème ligne, puis la 2ème, puis la 4ème, etc.).

Mon post ressemble plus à du déboggage donc je ne vais pas solliciter encore votre aide et je posterai la cause et le remède lorsque j'y serai arrivé

[plaineR]

Je doute que ton status soit NEW , car ce que tu décris ressemble à ce que je pensais initialement.
=> essaie de mettre le code que je t'ai indiqué dans le POST-RECORD (éventuellement sans le if, comme ça tu pourras voir aussi pour ceux que tu crées à la souris)

[Magnus]

Oui pardon, le status est : INSERT.

[EDIT]
J'ai cherché un éventuel trigger WNRI qui modifierait le status de l'enregistement de NEW à INSERT mais je n'en ai pas dans le bloc courant.
Comme cet écran comporte 5 blocs avec 1 maitre et 4 détails avec pas mal de code et de triggers donc je ne sais pas comment optimiser ma recherche de l'instruction (ou de la propriété d'un objet, etc.) qui ferait passer le status de NEW à INSERT.

Aurais-tu un moyen de déterminer efficacement l'instruction (l'objet) incriminé ?
[/EDIT]

[Magnus]

Je ressors ce vieux thread que j'ai lancé parce que j'ai enfin déterminé l'origine du changement de statut (grâce au déboggueur forms 9i).

En effet, il s'agit d'une fonction de récupération de libellé dans le trigger niveau bloc POST-QUERY qui fait passer le statut de QUERY à CHANGED.
Bien que les zones libellés ne soient pas base table, le statut du record passe de QUERY à CHANGED.

Mais, contrairement à ce qui est indiqué dans la doc forms 9i :

The following table illustrates the valid transition states of a record.
Current Status Target Status
NEW QUERY INSERT CHANGED
NEW yes yes1 yes2 no
QUERY yes4 yes no yes
INSERT yes4 yes3 yes no
CHANGED yes4 no no yes

il est possible de repositionner le statut de CHANGED à QUERY via l'instruction suivante à la fin de ce trigger :

Code :

SET_RECORD_PROPERTY(:SYSTEM.TRIGGER_RECORD, 'B3', STATUS, QUERY_STATUS);