[forms 9i] modifier dynamiquement la colonne source d'un item [Résolu]

[Magnus]

Bonjour tout le monde,

Sous forms 9i, je chercher à modifier dynamiquement la colonne sur laquelle pointe un item basé sur une table.
J'ai supposé que la procédure interne SET_ITEM_PROPERTY me permettrait d'effectuer ce traitement.

Malheureusement, la propriété COLUMN_NAME n'existe pas pour SET_ITEM_PROPERTY ; d'autant plus que cette propriété est disponible pour la procédure GET_ITEM_PROPERTY.

J'en déduis que le traitement que je cherche à mettre en place n'est pas possible.
Pouvez-vous me confirmer ou infirmer mon raisonnement ?

Merci d'avance.

[plaineR]

Non ce n'est pas possible. Mais il y a de nombreux moyens de contourner cela. C'est en affichage seul ou en insertion/maj que tu souhaites faire cela ?

[Magnus]

Salut plaineR,

Envoyé par plaineR

C'est en affichage seul ou en insertion/maj que tu souhaites faire cela ?

En insertion / maj / suppression et tu vois une multitude de manière de faire (i.e. sans passer par des centaines de lignes de code of course ) ?

[plaineR]

Une des méthodes les plus simples, c'est d'avoir les n items correspondant au n colonnes sources, superposés sur ton canvas et de n'afficher que celui que tu souhaites.

Une autre solution :
- en mode query la source de ton block est gérée sur une clause from, ce qui te permet de gérer par des case/decode la source de ta/tes colonnes dynamique
- en mode insertion/maj, ton block est basé sur la table (propriété DML Data target name)
- la/les colonnes dynamiques ont la propriétés query only à true
- tu gères dans le trigger cette/ces colonnes dynamiques.

Et le nombre de lignes de code est limité, évidemment

[Magnus]

Envoyé par plaineR

Une des méthodes les plus simples, c'est d'avoir les n items correspondant au n colonnes sources, superposés sur ton canvas et de n'afficher que celui que tu souhaites.

Effectivement je n'avais pas envisagé les choses sous sans angle.
Hormi un problème de placement des items lors de la conception, cette solution me paraît intéressante.

Envoyé par plaineR

Une autre solution :
- en mode query la source de ton block est gérée sur une clause from, ce qui te permet de gérer par des case/decode la source de ta/tes colonnes dynamique
- en mode insertion/maj, ton block est basé sur la table (propriété DML Data target name)
- la/les colonnes dynamiques ont la propriétés query only à true
- tu gères dans le trigger cette/ces colonnes dynamiques.

Désolé, j'ai du mal à te suivre :
- qu'appelles-tu "mode query" ou "mode insertion / maj" ? Le type de bloc ?
- dans le dernier point tu parles des triggers ON-INSERT, ON-UPDATE et ON-DELETE ?

[SheikYerbouti]

bonjour,

peut-on connaitre la raison d'une telle fonctionalité ?

[plaineR]

Envoyé par Magnus

- qu'appelles-tu "mode query" ou "mode insertion / maj" ? Le type de bloc ?

En fait depuis forms6i, il est possible de discerner la source de la requête (ce que j'appelle le mode query) et la source de destination (table mise à jour, ce que j'appelle le mode insertion/maj). J'espère avoir été plus clair, sinon je te donnerai un exemple.

- dans le dernier point tu parles des triggers ON-INSERT, ON-UPDATE et ON-DELETE ?

Non, je parle des triggers pre-insert et pre-update (excuse moi je ne me suis pas relu et je pensais avoir indiqué les triggers)

[Magnus]

Salut Sheikyerbouti,

J'ai un client qui me demande sans cesse depuis environ 6 mois d'ajouter des fonctionnalités à un écran complexe.
En simplifié, dans un onglet, j'ai une matrice ayant infinité de lignes (i.e. bloc multi lignes) et d'environ 20 colonnes dynamiques (elles résultent d'un paramétrage) pour lesquelles l'utilisateur peut modifier TEMPORAIREMENT les valeurs.

Lorsque j'effectue un certain traitement dans cet écran, j'ai besoin de récupérer ces valeurs pour faire des calculs.
Actuellement, j'utilise 2 variables pour chaque cellule correspondant à :
- l'identifiant de la cellule
- la valeur de la cellule.

Par conséquent, je dois modifier ce traitement pour gérer 2*20 = 40 nouvelles variables et je me disais que de baser mes colonnes me simplifierait la tâche.
Le problème de rendre ces colonnes base table est de pouvoir valider toutes les modifications apportées en dehors de cet onglet mais SURTOUT PAS les valeurs que l'utilisateur a saisi dans ces cellules.

Heu... je suis clair ?
Vous voyez une manière efficace de mettre en place cette fonctionnalité sur ces 20 colonnes ?

[plaineR]

Si j'ai bien compris ce que tu veux faire, la deuxième solution que je t'ai proposée semble parfaitement adaptée à ton besoin.

[Magnus]

Envoyé par plaineR

Si j'ai bien compris ce que tu veux faire, la deuxième solution que je t'ai proposée semble parfaitement adaptée à ton besoin.

Je me suis perdu entre ce que je voulais faire, la solution que j'ai commencé et fini d'implémenter
Finalement tes explications sont probablement claires et répondent à ma question plaineR mais je suis incapable de te le dire

Merci de ton coup de main.

[EDIT]en fait, j'ai lu tes explications qui me semblent claires mais ce qui me bloque c'est cette nouvelle fonctionnalité de la version 9i.
Je dois t'avouer que je ne comprends pas trop comment un bloc peut être basé sur une clause FROM.
Pour ma curiosité personnelle, tu n'aurais pas un exemple justifiant l'intérêt d'une telle fonctionnalité et détaillant son principe ?
[/EDIT]

[plaineR]

En prenant un exemple simple :
tu as 2 tables :
- une table des employes EMP (EMP_ID, EMP_NAME)
- une table des évolutions salariales SAL (EMP_ID, DATE_AUGMENTATION, SALAIRE)

Tu veux afficher et pouvoir faire des recherches sur le nom du salarié, sur la date d'augmentation et sur les salaires (via enter_query), mais également corriger la date d'augmentation ou le salaire
=> tu es obligé d'avoir comme colonnes basée EMP_NAME, DATE_AUGMENTATION et SALAIRE

Dans les propriétés de mon block, je mets donc :
* pour que la requête soit basée sur la jointure entre mes 2 tables :
- database block = yes
- query datasource type = from clause
- query datasource name = select emp_name, date_augmentation, salaire from emp, sal where emp.emp_id = sal.emp_id
* pour la gestion de mes maj
- DML data target type = table
- DML date target name = SAL
Ce que je complète par les propriétés de l'item EMP_NAME :
- query_only = yes (ne sera pas pris en compte dans l'instruction d'update)

=> mon block m'affichera le résultat de ma jointure et mettera à jour ma table SAL.

Attention, il faut penser à définir les items représentant la clé unique, en mettant à true la propriété primary key pour les items concernés (ici emp_id, date_augmentation).

Cette fonctionnalité a plusieurs intérêts :
- jointures que tu veux pouvoir requêter, mais une seule table mise à jour
- affichage d'informations qui n'appartiennent pas à la table mais qui sont des critères de tris intéressants (exemple résultat de fonction de regroument)
- et surtout pour des raisons de perf (encore plus vrai en mode web) : cela te permet de remplacer le post-query (qui exécute n fois la même requête) par une jointure.

J'espère avoir répondu à tes interrogations sur le sujet

[Magnus]

Ok ton exemple est très clair mais personnellement, si j'avais du l'implémenter j'aurais opté pour une relation maitre - détail avec 2 blocs de données chacun correspondant à une des 2 tables.

Les performances mises à part, je pense qu'en terme d'ergonomie de l'écran final, de temps de développement, de nombre de lignes de code, etc. les 2 solutions sont sensiblement équivalentes ?

Merci encore.

[plaineR]

En terme d'ergonomie, non, je pense que c'est différent : dans la solution maître-détail, il n'est pas possible de combiner des recherches (enter-query) sur le nom du salarié et sur la date d'augmentation par exemple. L'utilisateur est obligé dans un premier temps de rechercher le salarié, puis la date d'augmentation. C'était cela que je souhaitais justement éviter.

[Magnus]

Envoyé par plaineR

En terme d'ergonomie, non, je pense que c'est différent : dans la solution maître-détail, il n'est pas possible de combiner des recherches (enter-query) sur le nom du salarié et sur la date d'augmentation par exemple. L'utilisateur est obligé dans un premier temps de rechercher le salarié, puis la date d'augmentation. C'était cela que je souhaitais justement éviter.

Tu m'as convaincu, tu es vraiment trop fort petit génie