Ca fonctionne comme ça, je ne touche plus à rien... merci en tous cas doc, j'avais essayé tout ce que tu as utilisé (y compris essayé les 4 jointures qui aboutissaient toutes à un résultat faux pour moi -_-) je n'avais pas du traiter les choses dans le bon ordre... Encore que non, je n'avais pas réessayé les jointures avec les vues...
Le 22 avril 2010 09:45, ribotb <rib...@gmail.com> a écrit : > La requête me semble correcte... et on peut supprimer la condition IFNULL , > superflue , compte tenu de mes remarques sur le NULL. > > Le 22/04/2010 08:53, ribotb a écrit : >> >> J'ai exécuté la requête Regime_allocations_part2_CMSA qui ne rend aucun >> enregistrement (sans vérifier si c'est le résultat attendu ou non mais à >> première vue la requête me semble correcte) . >> >> On est donc bien dans le cas de mon "théorème" : "s'il n'y a pas >> d'enregistrement dans l'ensemble de données les deux fonctions >> [COUNT(*) ou COUNT(champ)] renvoient 0." >> >> Donc je ne comprends pas pourquoi on ne récupère pas 0. >> >> >> Le 21/04/2010 23:51, Docgranville a écrit : >>> >>> ribotb a écrit : >>>> >>>> Ça devrait renvoyer 0 : >>>> "COUNT(*) et COUNT(FieldName) ne renvoient jamais NULL :* s'il n'y a >>>> pas d'enregistrement dans l'ensemble de données les deux fonctions >>>> renvoient 0.* Ainsi, COUNT(FieldName) renvoie 0 si tous les champs >>>> FieldName dans l'ensemble de données sont >>>> NULL.". >>>> >>>> Je suis" sec" . >>>> >>> Je rappelle ce que j'ai dit dans mon second message (celui de 19h04) et >>> dont je pense qu'il faut y voir l'origine de la difficulté rencontrée par >>> Marie-Pierre : sa requête porte sur une vue (donc sur le résultat d'une >>> requête) qui elle même ne renvoie AUCUN tuple ; la vue ne comportant donc >>> aucun enregistrement, je pense que l'instruction ifnull ne peut pas remplir >>> son office ; cette instruction peut substituer une valeur spécifique à un >>> champ "null" d'un tuple mais encore faut-il qu'il y ait un tuple ; en >>> l'occurrence (c'est un cas particulier) il n'y a pas de champ "null" auquel >>> substituer la valeur définie, puisque ce champ n'existe pas (il n'existe que >>> quand il y a un tuple pour le porter). >>> >>> C'est l'explication qui m'apparaît la plus plausible pour le résultat >>> constaté. >>> >>> A+ >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org >>> For additional commands, e-mail: users-h...@fr.openoffice.org >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org >> For additional commands, e-mail: users-h...@fr.openoffice.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org > For additional commands, e-mail: users-h...@fr.openoffice.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org For additional commands, e-mail: users-h...@fr.openoffice.org
