[Résolu] IF avec condition sur valeur champ deux tables

[TCHANTCHE]

Bonjour,

Me revoilà.

J'ai une nouvelle question.

Je travaille avec SRB.

Dans le but de réaliser un rapport "universel" qui ne doit pas être modifié suite à une modification de condition, je désire écrire une formule IF avec comme condition la valeur d'un champ d'une table comparé à la valeur d'une autre table.

Je m'explique:

J'ai une table par exemple, table1 dans laquelle il y a un champ nommé MOIS_IMPUT avec des valeurs 10 pour le mois d'octobre, 11 pour le mois de novembre etc.

J'ai une autre table nommée table2 avec un seul champ [MOIS] qui contient la valeur du mois que je désire traiter par exemple 10.

Maintenant, je vais dans mon rapport et je veux qu'il ne traite que les données qui remplissent la condition [MOIS_IMPUT] de la table1 = [MOIS] de la table2.

La fonction ressemblerait à ceci:

IF ([MOIS_IMPUT] de la table 1 = [MOIS] de la table2; Réaliser la fonction; Ne rien faire)

Quelle est la syntaxe à utiliser dans cette formule?

Il n'est pas nécessaire de vous joindre une base en annexe puisqu'il s'agit d'une question de programmation.

Merci d'avance.

tchantche

[squenson]

Bonjour,

Personnellement, j'essaie de ne pas mettre de logique dans mes rapports. Pour cela je passe (presque) toujours par une requête intermédiaire, et mon rapport se base sur le contenu de cette requête pour produire le résultat final. L'avantage, c'est que je peux facilement copier/coller le résultat de la requête dans un tableur pour une analyse rapide.

[TCHANTCHE]

Merci Squenson,

Merci pour l'info mais cela ne répond pas à ma question sur la syntaxe dans la fonction IF.

Si on peut obtenir le résultat désiré via une requête, il doit bien y avoir une possibilité de le faire dans un rapport, et comme à ma connaissance il n'y a pas de possibilité d'obtenir le code source de la requête, la fonction utilisée dans la requête est donc inconnue. Sans quoi, ce serait facile de reporter la fonction dans le rapport.

Personnellement, je n'utilise pas de requête par habitude car bien que je sois nouveau sur openoffice base, j'ai réalisé un programme de gestion d'un école qui donnait et donne toujours des cours du soir en langues, il y a plus de 5000 élèves et des dizaines de langues, ce fut un travail énorme et sans fin car les contraintes de rapport demandées par les ministères (pour obtenir les subsides par exemple) étaient modifiées régulièrement.

Cette base de donnée tournait avec un programme Unisys pour ordinateurs B20 et permettait de produire des rapport avec des conditions de tri, impression etc extrêmement complexes. Ce programme avait été développé par Convergent Technologies à Santa Clara California, où j'ai eu la chance de me rendre pour suivre des cours orientés hardware ( ce qui est ma principale spécialité). J'ai toujours évité la programmation car je trouve que c'est un travail ingrat qui n'est jamais finalisé, il y a toujours des modifications à faire. Dans le hardware, quand la panne est trouvée et réparée, le problème est résolu. Je devais quand même pousser un peu plus loin car il fallait que je détermine la cause de la défaillance du chip, en effet un chip d'une marque tombait plus en panne qu'un équivalent d'une autre marque par exemple. C'est donc pour tracer tout cela et pouvoir rédiger des ATI (Advanced Technical Information) qui étaient destinées à tous les techniciens en charge de la maintenance de l'ordinateur, que j'ai commencé à utiliser ce programme de gestion de base de donnée.

Bien à toi.

Tchantche

[Pierre-Yves Samyn]

Bonjour

Si on peut obtenir le résultat désiré via une requête, il doit bien y avoir une possibilité de le faire dans un rapport

La source de données d'un rapport n'est définie que pour le "niveau" le plus haut (rapport donc) vs les formulaires/sous-formulaires qui disposent chacun de cette propriété. Pour les rapports on peut utiliser une table, une requête ou une instruction SQL.

Passer par une requête permet de bâtir et "tester" son expression SQL plus facilement via le mode ébauche (qui permet la sélection des tables, requêtes, champs) et plus sûrement (pas de risque de fautes de frappe).

Cela étant dit, pour revenir à ton sujet, en respectant tes contraintes (rapport dynamique s'adaptant au contenu d'une table "paramètre), je m'inspirerais du fil suivant (premier exemple) :
viewtopic.php?f=29&t=14662

Dans cet exemple on utilise une table paramètre (sélection) pour ensuite filtrer dans un sous-formulaire. Pour un rapport il suffit de créer une requête (instruction SQL si tu ne veux pas de requête) mettant en relation la table et le "reste" des données.

Dans l'exemple joint, tu peux tester en modifiant le contenu de la table paramètre par le formulaire Prénom.

Une autre solution serait de recourir à la programmation pour bâtir le SQL source du rapport par programme. La section programmation du forum comprend des exemples de mise en œuvre.

Il n'est pas nécessaire de vous joindre une base en annexe puisqu'il s'agit d'une question de programmation.

Ceci me semble erroné sur plusieurs points :

• La solution proposée ne repose pas sur de la programmation
• Si c'était le cas, il aurait fallu poser la question dans la section ad hoc du forum
• J'ai été obligé d'utiliser un de mes exemples pour illustrer ma proposition de solution. Travailler directement sur ta base aurait été plus simple.

[TCHANTCHE]

Bonjour Pierre-Yves,

La source de données d'un rapport n'est définie que pour le "niveau" le plus haut (rapport donc) vs les formulaires/sous-formulaires qui disposent chacun de cette propriété. Pour les rapports on peut utiliser une table, une requête ou une instruction SQL.

Donc, si j'ai bien compris, je crée une requête avec mes conditions, ensuite je passe en vue du code SQL de la requête et je copie le code SQL (éventuellement modifié suivant mes critères) que je reporte dans la page détails du rapport en sélectionnant SQL et non table ni requête.

C'est correct?

Si c'est cela, alors c'est la solution sublime que je cherchais afin de ne pas faire de requête sauf pour débugger le code SQL et n'avoir qu'un seul rapport quel que soit le mois à traiter.

Bien à toi.

tchantche

[Pierre-Yves Samyn]

Donc, si j'ai bien compris, je crée une requête avec mes conditions, ensuite je passe en vue du code SQL de la requête et je copie le code SQL (éventuellement modifié suivant mes critères) que je reporte dans la page détails du rapport en sélectionnant SQL et non table ni requête.

C'est correct?

Oui, si ce n'est que, comme dit précédemment, c'est au niveau "le plus haut" (i.e. "rapport" dans le navigateur de rapport) que figure l'onglet et les propriétés Données, et non au niveau de la section Détail...

[TCHANTCHE]

Superbe Pierre-Yves,

J'ai recopié le code SQL de ma requête que j'ai modifié en fonction de ma condition d'équivalence de la valeur du mois dans la base principale et de celle du fichier de contrôle ( ce dernier n'a qu'un seul champ soit le numéro du mois désiré dans les rapports), et j'ai fait un collage de la fonction dans la zone source des données du rapport.

CELA FONCTIONNE SUPERBEMENT BIEN.

J'ai même passé une partie de la nuit à modifier tous mes rapports avec les mêmes paramètres.

Maintenant, je sais sortir des rapports par mois et comme je passe par FinePrint pour l'impression, (cerise sur le gâteau) , je fais des livrets (booklet).
J'utilise une imprimante laser professionnelle HP-4050-N connectée sur mon réseau (achetée 45 euros!!, capacité du toner 10.000 pages - 500 feuilles dans le chargeur de papier- moins de 40 euros la cartouche pour 10.000 pages sur Ebay via Allemagne- Cool).

Il ne reste plus qu'a résoudre quelques détails dont:

1. Conserver la valeur d'un champ d'un enregistrement dans le champ suivant, j'ai recu un réponse à cette question mais je ne parviens pas à la faire fonctionner. Je n'ai pas encore investiguer les macros.
2. Voir ce qui se trouve dans un pied de page, car dans un rapport, pas das les autres, j'ai un pied de page qui a une hauteur de +- 5cm, qui apparemment ne contient rien (mais cela n'est pas sûr), dont je ne parviens pas à réduire la hauteur. Je désire placer simplement le numéro de la page. page x de y. La fonction fonctionne mais mon pied de page est trop grand dans ce rapport.
3. Dernier problème à résoudre, c'est l'accès direct via une page switchboard externe à open office base. J'ai aussi reçu une réponse concernant ce sujet mais je n'ai rien compris.
4. Je vais devoir modifier ma base de donnée pour intégrer l'année car bientôt nous quitterons 2009 pour 2010, jusqu'au mois 9 (avant le début de mes enodage 2009), pas de problèmes mais après il y aura un problème en 2010 lorsque le mois d'imputation sera le même en 2010 que celui en 2009 . Donc un champ année doit être ajouté et encore une fois modifier mes rapports.
J'y pense en écrivant ce message, pourquoi ne pas créer une table avec mes fonctions SQL, et y faire référence dans les rapports ainsi il ne serait plus nécessaire de modifier tous les rapports un par un (Idée à mettre dans la liste - à faire).

Je traite les problèmes suivant leurs priorités, maintenant que les rapports sont comme je le désire, je vais continuer mes investigations pour résoudre les points 1.2.3, en ce qui me concerne je m'y retrouve dans mon application mais un néophyte sera peut-être perdu, il faut donc simplifier l'accès à l'encodage et la génération des rapports.

Encore merci pour ce coup de pouce, on a tous besoin d'un gourou.

Tchantche