Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Le 23/04/2010 09:45, Marie-Pierre CORONEL a écrit : Salut, Il y a quelque chose qui pourrait me permettre de réduire le nombre de tables, c'est de jouer sur les clés (concaténation par exemple de civ+numéro de médiation, pen+numéro de médiation). J'ai vu qu'il y avait des fils sur le sujet dans le forum, mais prise par l'urgence, je n'ai pas planché le sujet. Je vais aller voir, si ça peut se faire sans programmation, ça allègerait considérablement la base. Bonjour Marie-Pierre, Je n'ai pas encore eu le temps de répondre utilement à ton message d'hier soir, j'essaierai de le faire ce week-end. En revanche, je ne vois pas bien par quel moyen la concaténation que tu évoques pourrait être de nature à réduire le nombre de tes tables. Pour moi, le point de départ de la réflexion, c'est que l'objectif de cette base étant de gérer des procédures, il est indispensable que celles-ci soient regroupées dans une seule et unique table ; je pense vraiment que, si la médiation elle-même s'adresse aux personnes, la base de son côté, constitue une aide à la gestion de la procédure et doit donc être centrée sur elle ; en conséquence, le numéro d'identification unique de la procédure (la clef primaire dans la table regroupant les procédures) servira ensuite dans les autres tables, à identifier les personnes concernées par cette procédure, les évènements affectant cette procédure, etc, etc... ; et je pense que ça facilitera grandement la sortie de statistiques (parce que elles, j'imagine bien qu'elles portent sur les procédures, pas sur les personnes). D'ailleurs, l'ambigüité que tu soulignais entre le nom et la fonction de ta table Demandeurs, vient (selon moi) du fait quelle a une double fonction : identifier les parties ET marquer la saisine du service ; même si elles sont intimement liées (s'il n'y a pas de personnes, il n'y a pas de conflit et donc pas de médiation) et qu'une distinction peut paraître artificielle, je crois préférable (pour la souplesse d'utilisation et de maintenance ultérieure de ta base, d'enregistrer dans des tables séparées les données relatives aux procédures d'une part et celles relatives aux personnes concernées d'autre part. Il me semble que c'est cette démarche là qui devrait te permettre de réduire un peu le nombre de tes tables. A+ - To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org For additional commands, e-mail: users-h...@fr.openoffice.org
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
En fait, ça m'évitait potentiellement d'ajouter un champ dans les tables secondaires qui contienne civil ou pénal (un connecteur pour savoir à quelle table on se branche) de manière à différencier la médiation civile 0 de la médiation pénale 0. Mais évidemment, moi je reste sur 2 procédures et toi tu défends la procédure unique :D De mon côté, j'ai interrogé le service informatique de la mairie, parce que si j'utilisais MySQL, ce n'est pas sur mon PC qu'il devrait être installé mais sur l'un de leurs serveurs... Le 23 avril 2010 10:37, Docgranville docgranvi...@aol.com a écrit : Le 23/04/2010 09:45, Marie-Pierre CORONEL a écrit : Salut, Il y a quelque chose qui pourrait me permettre de réduire le nombre de tables, c'est de jouer sur les clés (concaténation par exemple de civ+numéro de médiation, pen+numéro de médiation). J'ai vu qu'il y avait des fils sur le sujet dans le forum, mais prise par l'urgence, je n'ai pas planché le sujet. Je vais aller voir, si ça peut se faire sans programmation, ça allègerait considérablement la base. Bonjour Marie-Pierre, Je n'ai pas encore eu le temps de répondre utilement à ton message d'hier soir, j'essaierai de le faire ce week-end. En revanche, je ne vois pas bien par quel moyen la concaténation que tu évoques pourrait être de nature à réduire le nombre de tes tables. Pour moi, le point de départ de la réflexion, c'est que l'objectif de cette base étant de gérer des procédures, il est indispensable que celles-ci soient regroupées dans une seule et unique table ; je pense vraiment que, si la médiation elle-même s'adresse aux personnes, la base de son côté, constitue une aide à la gestion de la procédure et doit donc être centrée sur elle ; en conséquence, le numéro d'identification unique de la procédure (la clef primaire dans la table regroupant les procédures) servira ensuite dans les autres tables, à identifier les personnes concernées par cette procédure, les évènements affectant cette procédure, etc, etc... ; et je pense que ça facilitera grandement la sortie de statistiques (parce que elles, j'imagine bien qu'elles portent sur les procédures, pas sur les personnes). D'ailleurs, l'ambigüité que tu soulignais entre le nom et la fonction de ta table Demandeurs, vient (selon moi) du fait quelle a une double fonction : identifier les parties ET marquer la saisine du service ; même si elles sont intimement liées (s'il n'y a pas de personnes, il n'y a pas de conflit et donc pas de médiation) et qu'une distinction peut paraître artificielle, je crois préférable (pour la souplesse d'utilisation et de maintenance ultérieure de ta base, d'enregistrer dans des tables séparées les données relatives aux procédures d'une part et celles relatives aux personnes concernées d'autre part. Il me semble que c'est cette démarche là qui devrait te permettre de réduire un peu le nombre de tes tables. 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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Ah et je suis parfaitement d'accord, le point d'entrée devrait être la procédure. Mais le problème c'est qu'une procédure ne peut contenir plusieurs conflits, alors qu'un même conflit peut contenir plusieurs procédures... Le 23 avril 2010 11:28, Marie-Pierre CORONEL mariepierre@gmail.com a écrit : En fait, ça m'évitait potentiellement d'ajouter un champ dans les tables secondaires qui contienne civil ou pénal (un connecteur pour savoir à quelle table on se branche) de manière à différencier la médiation civile 0 de la médiation pénale 0. Mais évidemment, moi je reste sur 2 procédures et toi tu défends la procédure unique :D De mon côté, j'ai interrogé le service informatique de la mairie, parce que si j'utilisais MySQL, ce n'est pas sur mon PC qu'il devrait être installé mais sur l'un de leurs serveurs... Le 23 avril 2010 10:37, Docgranville docgranvi...@aol.com a écrit : Le 23/04/2010 09:45, Marie-Pierre CORONEL a écrit : Salut, Il y a quelque chose qui pourrait me permettre de réduire le nombre de tables, c'est de jouer sur les clés (concaténation par exemple de civ+numéro de médiation, pen+numéro de médiation). J'ai vu qu'il y avait des fils sur le sujet dans le forum, mais prise par l'urgence, je n'ai pas planché le sujet. Je vais aller voir, si ça peut se faire sans programmation, ça allègerait considérablement la base. Bonjour Marie-Pierre, Je n'ai pas encore eu le temps de répondre utilement à ton message d'hier soir, j'essaierai de le faire ce week-end. En revanche, je ne vois pas bien par quel moyen la concaténation que tu évoques pourrait être de nature à réduire le nombre de tes tables. Pour moi, le point de départ de la réflexion, c'est que l'objectif de cette base étant de gérer des procédures, il est indispensable que celles-ci soient regroupées dans une seule et unique table ; je pense vraiment que, si la médiation elle-même s'adresse aux personnes, la base de son côté, constitue une aide à la gestion de la procédure et doit donc être centrée sur elle ; en conséquence, le numéro d'identification unique de la procédure (la clef primaire dans la table regroupant les procédures) servira ensuite dans les autres tables, à identifier les personnes concernées par cette procédure, les évènements affectant cette procédure, etc, etc... ; et je pense que ça facilitera grandement la sortie de statistiques (parce que elles, j'imagine bien qu'elles portent sur les procédures, pas sur les personnes). D'ailleurs, l'ambigüité que tu soulignais entre le nom et la fonction de ta table Demandeurs, vient (selon moi) du fait quelle a une double fonction : identifier les parties ET marquer la saisine du service ; même si elles sont intimement liées (s'il n'y a pas de personnes, il n'y a pas de conflit et donc pas de médiation) et qu'une distinction peut paraître artificielle, je crois préférable (pour la souplesse d'utilisation et de maintenance ultérieure de ta base, d'enregistrer dans des tables séparées les données relatives aux procédures d'une part et celles relatives aux personnes concernées d'autre part. Il me semble que c'est cette démarche là qui devrait te permettre de réduire un peu le nombre de tes tables. 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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Le 23/04/2010 11:29, Marie-Pierre CORONEL a écrit : Ah et je suis parfaitement d'accord, le point d'entrée devrait être la procédure. Mais le problème c'est qu'une procédure ne peut contenir plusieurs conflits, alors qu'un même conflit peut contenir plusieurs procédures... Selon moi, ce n'est pas un problème. Il faut déterminer un point d'entrée ; ensuite, qu'on l'appelle conflit, procédure, médiation, grand happening, manifestation ou xgrtpjoif, ça ne change pas grand chose. Appelons le conflit si tu veux, mais en tout cas, c'est ce truc là qui constitue ton point central et dont la clef primaire servira de clef externe dans un certain nombre d'autres tables ; ensuite, tu crées une une table parties, une table procédures (au sens que tu lui donnes dans ton message ci-dessus, puisque la table médiation est déjà utilisée) et une table suivi (dont la clef externe sera la clef primaire de la table procédures) et toutes le informations sont centralisées dans des tables uniques (il n'y a pas moitié des noms à un endroit d'une table et l'autre moitié à un autre endroit de la même table, pas moitié des procédures -toujours au sens de ton message- dans une table et l'autre moitié dans une autre, etc...) Certes, je viens de rajouter une table, mais j'ai aussi réuni en une seule, tes tables procédures, donc on a égalité. (pour Mysql, dans un contexte mono-utilisateur, rien n'empêche qu'il soit sur le poste de l'utilisateur ; en fait, la notion serveur-client dans Mysql n'est qu'une notion logique, pas nécessairement matérielle ; le serveur Mysql et le client Mysql peuvent très bien être sur le même PC) A+ - To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org For additional commands, e-mail: users-h...@fr.openoffice.org
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Bonjour Marie-Pierre, bonjour Docgrainville, Je suis un peu vos échanges intéressants, aussi permettez-moi d'exprimer mon point de vue sur la démarche à envisager éventuellement. 1) Je pense qu'il ne faut pas chambouler la base actuelle, surtout si elle fonctionne de façon satisfaisante (je ne l'ai pas expertisée :-) aussi je me garderais de me prononcer sur cet aspect des choses). Le fait que OOo Base soit mono-poste n'est peut-être pas pour l'immédiat un handicap s'il y a une seule utilisatrice. Cette suggestion est le fruit de l'expérience :-) 2) On peut envisager parallèlement une refonte complète de la base (une sorte de version 2) et sur ce point il y a deux aspects à prendre en compte : - l'aspect conceptuel - l'aspect technique 3) La conception : Il faut d'abord concevoir le modèle conceptuel des données qui consiste à rechercher toutes les données à gérer, leurs règles de gestion, définir les entités et les relations, ainsi que les contraintes; La phase suivante consiste à normaliser le modèle. Il existe un certain nombre de formes normales qui permettent d'avoir une base stable (elle peut évoluer sans bobos), intègre malgré les mises à jour sur les données, et sans redondance d'informations. Les tables sont la matérialisation physique des relations définies lors de la conception. 4) L'implémentation physique : Il est certain que des vrais SGBDR (tels MySQL, PostgreSQL ou Firebird) sont préférables à OOo Base pour une utilisation professionnelle. Il n'en demeure pas moins que le modèle physique issu de la phase conception peut être implémenté éventuellement avec OOo Base (qui présente l'avantage de permettre de fabriquer assez simplement des formulaires plus ou moins complexes. Personnellement j'utilise Firebird (et aussi OOo Base, ça dépend du projet) comme serveur de bases de données et j'utilise IBEasy+ pour le développement des applications. Je cite ce logiciel car il prend en charge la phase conception (référentiel des données, manipulation des concepts de base : domaines, relations, attributs, etc., conception graphique de la base) Vous me direz que ceci est très théorique mais mon propos n'était que de suggérer à Marie-Pierre quelques axes de réflexion pour développer sa future éventuelle base de données :-) Bonne journée, Bernard Le 23/04/2010 11:29, Marie-Pierre CORONEL a écrit : Ah et je suis parfaitement d'accord, le point d'entrée devrait être la procédure. Mais le problème c'est qu'une procédure ne peut contenir plusieurs conflits, alors qu'un même conflit peut contenir plusieurs procédures... Le 23 avril 2010 11:28, Marie-Pierre CORONEL mariepierre@gmail.com a écrit : En fait, ça m'évitait potentiellement d'ajouter un champ dans les tables secondaires qui contienne civil ou pénal (un connecteur pour savoir à quelle table on se branche) de manière à différencier la médiation civile 0 de la médiation pénale 0. Mais évidemment, moi je reste sur 2 procédures et toi tu défends la procédure unique :D De mon côté, j'ai interrogé le service informatique de la mairie, parce que si j'utilisais MySQL, ce n'est pas sur mon PC qu'il devrait être installé mais sur l'un de leurs serveurs... Le 23 avril 2010 10:37, Docgranvilledocgranvi...@aol.com a écrit : Le 23/04/2010 09:45, Marie-Pierre CORONEL a écrit : Salut, Il y a quelque chose qui pourrait me permettre de réduire le nombre de tables, c'est de jouer sur les clés (concaténation par exemple de civ+numéro de médiation, pen+numéro de médiation). J'ai vu qu'il y avait des fils sur le sujet dans le forum, mais prise par l'urgence, je n'ai pas planché le sujet. Je vais aller voir, si ça peut se faire sans programmation, ça allègerait considérablement la base. Bonjour Marie-Pierre, Je n'ai pas encore eu le temps de répondre utilement à ton message d'hier soir, j'essaierai de le faire ce week-end. En revanche, je ne vois pas bien par quel moyen la concaténation que tu évoques pourrait être de nature à réduire le nombre de tes tables. Pour moi, le point de départ de la réflexion, c'est que l'objectif de cette base étant de gérer des procédures, il est indispensable que celles-ci soient regroupées dans une seule et unique table ; je pense vraiment que, si la médiation elle-même s'adresse aux personnes, la base de son côté, constitue une aide à la gestion de la procédure et doit donc être centrée sur elle ; en conséquence, le numéro d'identification unique de la procédure (la clef primaire dans la table regroupant les procédures) servira ensuite dans les autres tables, à identifier les personnes concernées par cette procédure, les évènements affectant cette procédure, etc, etc... ; et je pense que ça facilitera grandement la sortie de statistiques (parce que elles, j'imagine bien qu'elles portent sur les procédures, pas sur les personnes). D'ailleurs, l'ambigüité que tu soulignais entre le nom et la fonction de ta table Demandeurs, vient (selon moi) du fait
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
A docgranville : concernant l'utilisation de base en production, je te recommande d'aller faire un petit tour sur le forum, tu verras qu'on est de plus en plus nombreux sur le sujet... je réponds actuellement à quelqu'un qui veut mettre sur base sont cahier des variables de paye par exemple. A Bernard, sur la théorie c'est là que je suis la plus forte, j'ai même eu dans le temps mon concours de rédacteur option programmeur sur... les principes de la base de données relationnelle... C'est sur la mise en pratique que 20 ans après je pêche :D Le 23 avril 2010 13:08, ribotb rib...@gmail.com a écrit : Bonjour Marie-Pierre, bonjour Docgrainville, Je suis un peu vos échanges intéressants, aussi permettez-moi d'exprimer mon point de vue sur la démarche à envisager éventuellement. 1) Je pense qu'il ne faut pas chambouler la base actuelle, surtout si elle fonctionne de façon satisfaisante (je ne l'ai pas expertisée :-) aussi je me garderais de me prononcer sur cet aspect des choses). Le fait que OOo Base soit mono-poste n'est peut-être pas pour l'immédiat un handicap s'il y a une seule utilisatrice. Cette suggestion est le fruit de l'expérience :-) 2) On peut envisager parallèlement une refonte complète de la base (une sorte de version 2) et sur ce point il y a deux aspects à prendre en compte : - l'aspect conceptuel - l'aspect technique 3) La conception : Il faut d'abord concevoir le modèle conceptuel des données qui consiste à rechercher toutes les données à gérer, leurs règles de gestion, définir les entités et les relations, ainsi que les contraintes; La phase suivante consiste à normaliser le modèle. Il existe un certain nombre de formes normales qui permettent d'avoir une base stable (elle peut évoluer sans bobos), intègre malgré les mises à jour sur les données, et sans redondance d'informations. Les tables sont la matérialisation physique des relations définies lors de la conception. 4) L'implémentation physique : Il est certain que des vrais SGBDR (tels MySQL, PostgreSQL ou Firebird) sont préférables à OOo Base pour une utilisation professionnelle. Il n'en demeure pas moins que le modèle physique issu de la phase conception peut être implémenté éventuellement avec OOo Base (qui présente l'avantage de permettre de fabriquer assez simplement des formulaires plus ou moins complexes. Personnellement j'utilise Firebird (et aussi OOo Base, ça dépend du projet) comme serveur de bases de données et j'utilise IBEasy+ pour le développement des applications. Je cite ce logiciel car il prend en charge la phase conception (référentiel des données, manipulation des concepts de base : domaines, relations, attributs, etc., conception graphique de la base) Vous me direz que ceci est très théorique mais mon propos n'était que de suggérer à Marie-Pierre quelques axes de réflexion pour développer sa future éventuelle base de données :-) Bonne journée, Bernard Le 23/04/2010 11:29, Marie-Pierre CORONEL a écrit : Ah et je suis parfaitement d'accord, le point d'entrée devrait être la procédure. Mais le problème c'est qu'une procédure ne peut contenir plusieurs conflits, alors qu'un même conflit peut contenir plusieurs procédures... Le 23 avril 2010 11:28, Marie-Pierre CORONEL mariepierre@gmail.com a écrit : En fait, ça m'évitait potentiellement d'ajouter un champ dans les tables secondaires qui contienne civil ou pénal (un connecteur pour savoir à quelle table on se branche) de manière à différencier la médiation civile 0 de la médiation pénale 0. Mais évidemment, moi je reste sur 2 procédures et toi tu défends la procédure unique :D De mon côté, j'ai interrogé le service informatique de la mairie, parce que si j'utilisais MySQL, ce n'est pas sur mon PC qu'il devrait être installé mais sur l'un de leurs serveurs... Le 23 avril 2010 10:37, Docgranvilledocgranvi...@aol.com a écrit : Le 23/04/2010 09:45, Marie-Pierre CORONEL a écrit : Salut, Il y a quelque chose qui pourrait me permettre de réduire le nombre de tables, c'est de jouer sur les clés (concaténation par exemple de civ+numéro de médiation, pen+numéro de médiation). J'ai vu qu'il y avait des fils sur le sujet dans le forum, mais prise par l'urgence, je n'ai pas planché le sujet. Je vais aller voir, si ça peut se faire sans programmation, ça allègerait considérablement la base. Bonjour Marie-Pierre, Je n'ai pas encore eu le temps de répondre utilement à ton message d'hier soir, j'essaierai de le faire ce week-end. En revanche, je ne vois pas bien par quel moyen la concaténation que tu évoques pourrait être de nature à réduire le nombre de tes tables. Pour moi, le point de départ de la réflexion, c'est que l'objectif de cette base étant de gérer des procédures, il est indispensable que celles-ci soient regroupées dans une seule et unique table ; je pense vraiment que, si la médiation elle-même s'adresse aux personnes, la base de son côté, constitue une aide à
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Oui mais il semble quand même que la phase de conception ait été sautée si j'en juge par les remarques de docgrainville (je n'ai toujours pas ma propre idée de ta base car je n'ai pas beaucoup de temps pour m'y plonger). Certaines de ses remarques me laissent à penser que le modèle des données n'est pas normalisé (pas de 1ère forme normale, semble-t-il, ni peut-être de 2nde ou 3ème). Bon, je ne vais pas te faire un cours sur les formes normales de E.F. Codd, tu as du avoir l'occasion de les approcher quand tu travaillais sur les principes des bdd relationnelles. Bernard Le 23/04/2010 14:53, Marie-Pierre CORONEL a écrit : A docgranville : concernant l'utilisation de base en production, je te recommande d'aller faire un petit tour sur le forum, tu verras qu'on est de plus en plus nombreux sur le sujet... je réponds actuellement à quelqu'un qui veut mettre sur base sont cahier des variables de paye par exemple. A Bernard, sur la théorie c'est là que je suis la plus forte, j'ai même eu dans le temps mon concours de rédacteur option programmeur sur... les principes de la base de données relationnelle... C'est sur la mise en pratique que 20 ans après je pêche :D Le 23 avril 2010 13:08, ribotbrib...@gmail.com a écrit : Bonjour Marie-Pierre, bonjour Docgrainville, Je suis un peu vos échanges intéressants, aussi permettez-moi d'exprimer mon point de vue sur la démarche à envisager éventuellement. 1) Je pense qu'il ne faut pas chambouler la base actuelle, surtout si elle fonctionne de façon satisfaisante (je ne l'ai pas expertisée :-) aussi je me garderais de me prononcer sur cet aspect des choses). Le fait que OOo Base soit mono-poste n'est peut-être pas pour l'immédiat un handicap s'il y a une seule utilisatrice. Cette suggestion est le fruit de l'expérience :-) 2) On peut envisager parallèlement une refonte complète de la base (une sorte de version 2) et sur ce point il y a deux aspects à prendre en compte : - l'aspect conceptuel - l'aspect technique 3) La conception : Il faut d'abord concevoir le modèle conceptuel des données qui consiste à rechercher toutes les données à gérer, leurs règles de gestion, définir les entités et les relations, ainsi que les contraintes; La phase suivante consiste à normaliser le modèle. Il existe un certain nombre de formes normales qui permettent d'avoir une base stable (elle peut évoluer sans bobos), intègre malgré les mises à jour sur les données, et sans redondance d'informations. Les tables sont la matérialisation physique des relations définies lors de la conception. 4) L'implémentation physique : Il est certain que des vrais SGBDR (tels MySQL, PostgreSQL ou Firebird) sont préférables à OOo Base pour une utilisation professionnelle. Il n'en demeure pas moins que le modèle physique issu de la phase conception peut être implémenté éventuellement avec OOo Base (qui présente l'avantage de permettre de fabriquer assez simplement des formulaires plus ou moins complexes. Personnellement j'utilise Firebird (et aussi OOo Base, ça dépend du projet) comme serveur de bases de données et j'utilise IBEasy+ pour le développement des applications. Je cite ce logiciel car il prend en charge la phase conception (référentiel des données, manipulation des concepts de base : domaines, relations, attributs, etc., conception graphique de la base) Vous me direz que ceci est très théorique mais mon propos n'était que de suggérer à Marie-Pierre quelques axes de réflexion pour développer sa future éventuelle base de données :-) Bonne journée, Bernard Le 23/04/2010 11:29, Marie-Pierre CORONEL a écrit : Ah et je suis parfaitement d'accord, le point d'entrée devrait être la procédure. Mais le problème c'est qu'une procédure ne peut contenir plusieurs conflits, alors qu'un même conflit peut contenir plusieurs procédures... Le 23 avril 2010 11:28, Marie-Pierre CORONEL mariepierre@gmail.coma écrit : En fait, ça m'évitait potentiellement d'ajouter un champ dans les tables secondaires qui contienne civil ou pénal (un connecteur pour savoir à quelle table on se branche) de manière à différencier la médiation civile 0 de la médiation pénale 0. Mais évidemment, moi je reste sur 2 procédures et toi tu défends la procédure unique :D De mon côté, j'ai interrogé le service informatique de la mairie, parce que si j'utilisais MySQL, ce n'est pas sur mon PC qu'il devrait être installé mais sur l'un de leurs serveurs... Le 23 avril 2010 10:37, Docgranvilledocgranvi...@aol.coma écrit : Le 23/04/2010 09:45, Marie-Pierre CORONEL a écrit : Salut, Il y a quelque chose qui pourrait me permettre de réduire le nombre de tables, c'est de jouer sur les clés (concaténation par exemple de civ+numéro de médiation, pen+numéro de médiation). J'ai vu qu'il y avait des fils sur le sujet dans le forum, mais prise par l'urgence, je n'ai pas planché le sujet. Je vais aller voir, si ça peut se faire sans programmation, ça allègerait considérablement
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Et bien, je peux avoir fait des erreurs, mais il n'y a qu'à regarder le nombre de tables à attribut unique pour voir que j'ai cherché à les respecter. Après j'ai fait le choix de mettre dans une même table d'apparentes redondances (les mêmes éléments d'information sur les deux parties) mais ces éléments étant issus de tables, si les occurences changeaient demain, elles changeraient pour les deux parties par exemple sans qu'on soit obligés d'y veiller... Le 23 avril 2010 15:27, ribotb rib...@gmail.com a écrit : Oui mais il semble quand même que la phase de conception ait été sautée si j'en juge par les remarques de docgrainville (je n'ai toujours pas ma propre idée de ta base car je n'ai pas beaucoup de temps pour m'y plonger). Certaines de ses remarques me laissent à penser que le modèle des données n'est pas normalisé (pas de 1ère forme normale, semble-t-il, ni peut-être de 2nde ou 3ème). Bon, je ne vais pas te faire un cours sur les formes normales de E.F. Codd, tu as du avoir l'occasion de les approcher quand tu travaillais sur les principes des bdd relationnelles. Bernard Le 23/04/2010 14:53, Marie-Pierre CORONEL a écrit : A docgranville : concernant l'utilisation de base en production, je te recommande d'aller faire un petit tour sur le forum, tu verras qu'on est de plus en plus nombreux sur le sujet... je réponds actuellement à quelqu'un qui veut mettre sur base sont cahier des variables de paye par exemple. A Bernard, sur la théorie c'est là que je suis la plus forte, j'ai même eu dans le temps mon concours de rédacteur option programmeur sur... les principes de la base de données relationnelle... C'est sur la mise en pratique que 20 ans après je pêche :D Le 23 avril 2010 13:08, ribotbrib...@gmail.com a écrit : Bonjour Marie-Pierre, bonjour Docgrainville, Je suis un peu vos échanges intéressants, aussi permettez-moi d'exprimer mon point de vue sur la démarche à envisager éventuellement. 1) Je pense qu'il ne faut pas chambouler la base actuelle, surtout si elle fonctionne de façon satisfaisante (je ne l'ai pas expertisée :-) aussi je me garderais de me prononcer sur cet aspect des choses). Le fait que OOo Base soit mono-poste n'est peut-être pas pour l'immédiat un handicap s'il y a une seule utilisatrice. Cette suggestion est le fruit de l'expérience :-) 2) On peut envisager parallèlement une refonte complète de la base (une sorte de version 2) et sur ce point il y a deux aspects à prendre en compte : - l'aspect conceptuel - l'aspect technique 3) La conception : Il faut d'abord concevoir le modèle conceptuel des données qui consiste à rechercher toutes les données à gérer, leurs règles de gestion, définir les entités et les relations, ainsi que les contraintes; La phase suivante consiste à normaliser le modèle. Il existe un certain nombre de formes normales qui permettent d'avoir une base stable (elle peut évoluer sans bobos), intègre malgré les mises à jour sur les données, et sans redondance d'informations. Les tables sont la matérialisation physique des relations définies lors de la conception. 4) L'implémentation physique : Il est certain que des vrais SGBDR (tels MySQL, PostgreSQL ou Firebird) sont préférables à OOo Base pour une utilisation professionnelle. Il n'en demeure pas moins que le modèle physique issu de la phase conception peut être implémenté éventuellement avec OOo Base (qui présente l'avantage de permettre de fabriquer assez simplement des formulaires plus ou moins complexes. Personnellement j'utilise Firebird (et aussi OOo Base, ça dépend du projet) comme serveur de bases de données et j'utilise IBEasy+ pour le développement des applications. Je cite ce logiciel car il prend en charge la phase conception (référentiel des données, manipulation des concepts de base : domaines, relations, attributs, etc., conception graphique de la base) Vous me direz que ceci est très théorique mais mon propos n'était que de suggérer à Marie-Pierre quelques axes de réflexion pour développer sa future éventuelle base de données :-) Bonne journée, Bernard Le 23/04/2010 11:29, Marie-Pierre CORONEL a écrit : Ah et je suis parfaitement d'accord, le point d'entrée devrait être la procédure. Mais le problème c'est qu'une procédure ne peut contenir plusieurs conflits, alors qu'un même conflit peut contenir plusieurs procédures... Le 23 avril 2010 11:28, Marie-Pierre CORONEL mariepierre@gmail.com a écrit : En fait, ça m'évitait potentiellement d'ajouter un champ dans les tables secondaires qui contienne civil ou pénal (un connecteur pour savoir à quelle table on se branche) de manière à différencier la médiation civile 0 de la médiation pénale 0. Mais évidemment, moi je reste sur 2 procédures et toi tu défends la procédure unique :D De mon côté, j'ai interrogé le service informatique de la mairie, parce que si j'utilisais MySQL, ce n'est pas sur mon PC qu'il devrait être installé
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Par contre, il y a bien une erreur de conception que j'ai découverte ce soir. Cette erreur est issue des modifications qui m'ont été communiquées le 20 mars dernier alors que ma base était déjà toute montée... Il s'agit des critères ajoutés, attachés aux informations préalables, qui sont les mêmes que pour les médiations. Là c'est vrai, je n'ai pas réfléchi assez longtemps. Le 23 avril 2010 19:20, Marie-Pierre CORONEL mariepierre@gmail.com a écrit : Et bien, je peux avoir fait des erreurs, mais il n'y a qu'à regarder le nombre de tables à attribut unique pour voir que j'ai cherché à les respecter. Après j'ai fait le choix de mettre dans une même table d'apparentes redondances (les mêmes éléments d'information sur les deux parties) mais ces éléments étant issus de tables, si les occurences changeaient demain, elles changeraient pour les deux parties par exemple sans qu'on soit obligés d'y veiller... Le 23 avril 2010 15:27, ribotb rib...@gmail.com a écrit : Oui mais il semble quand même que la phase de conception ait été sautée si j'en juge par les remarques de docgrainville (je n'ai toujours pas ma propre idée de ta base car je n'ai pas beaucoup de temps pour m'y plonger). Certaines de ses remarques me laissent à penser que le modèle des données n'est pas normalisé (pas de 1ère forme normale, semble-t-il, ni peut-être de 2nde ou 3ème). Bon, je ne vais pas te faire un cours sur les formes normales de E.F. Codd, tu as du avoir l'occasion de les approcher quand tu travaillais sur les principes des bdd relationnelles. Bernard Le 23/04/2010 14:53, Marie-Pierre CORONEL a écrit : A docgranville : concernant l'utilisation de base en production, je te recommande d'aller faire un petit tour sur le forum, tu verras qu'on est de plus en plus nombreux sur le sujet... je réponds actuellement à quelqu'un qui veut mettre sur base sont cahier des variables de paye par exemple. A Bernard, sur la théorie c'est là que je suis la plus forte, j'ai même eu dans le temps mon concours de rédacteur option programmeur sur... les principes de la base de données relationnelle... C'est sur la mise en pratique que 20 ans après je pêche :D Le 23 avril 2010 13:08, ribotbrib...@gmail.com a écrit : Bonjour Marie-Pierre, bonjour Docgrainville, Je suis un peu vos échanges intéressants, aussi permettez-moi d'exprimer mon point de vue sur la démarche à envisager éventuellement. 1) Je pense qu'il ne faut pas chambouler la base actuelle, surtout si elle fonctionne de façon satisfaisante (je ne l'ai pas expertisée :-) aussi je me garderais de me prononcer sur cet aspect des choses). Le fait que OOo Base soit mono-poste n'est peut-être pas pour l'immédiat un handicap s'il y a une seule utilisatrice. Cette suggestion est le fruit de l'expérience :-) 2) On peut envisager parallèlement une refonte complète de la base (une sorte de version 2) et sur ce point il y a deux aspects à prendre en compte : - l'aspect conceptuel - l'aspect technique 3) La conception : Il faut d'abord concevoir le modèle conceptuel des données qui consiste à rechercher toutes les données à gérer, leurs règles de gestion, définir les entités et les relations, ainsi que les contraintes; La phase suivante consiste à normaliser le modèle. Il existe un certain nombre de formes normales qui permettent d'avoir une base stable (elle peut évoluer sans bobos), intègre malgré les mises à jour sur les données, et sans redondance d'informations. Les tables sont la matérialisation physique des relations définies lors de la conception. 4) L'implémentation physique : Il est certain que des vrais SGBDR (tels MySQL, PostgreSQL ou Firebird) sont préférables à OOo Base pour une utilisation professionnelle. Il n'en demeure pas moins que le modèle physique issu de la phase conception peut être implémenté éventuellement avec OOo Base (qui présente l'avantage de permettre de fabriquer assez simplement des formulaires plus ou moins complexes. Personnellement j'utilise Firebird (et aussi OOo Base, ça dépend du projet) comme serveur de bases de données et j'utilise IBEasy+ pour le développement des applications. Je cite ce logiciel car il prend en charge la phase conception (référentiel des données, manipulation des concepts de base : domaines, relations, attributs, etc., conception graphique de la base) Vous me direz que ceci est très théorique mais mon propos n'était que de suggérer à Marie-Pierre quelques axes de réflexion pour développer sa future éventuelle base de données :-) Bonne journée, Bernard Le 23/04/2010 11:29, Marie-Pierre CORONEL a écrit : Ah et je suis parfaitement d'accord, le point d'entrée devrait être la procédure. Mais le problème c'est qu'une procédure ne peut contenir plusieurs conflits, alors qu'un même conflit peut contenir plusieurs procédures... Le 23 avril 2010 11:28, Marie-Pierre CORONEL mariepierre@gmail.com a écrit : En fait, ça m'évitait
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Je viens de monter avec le SGBDR Firebird une toute petite base avec 2 tables (DEMANDEURS et MEDIATIONs qui remplace la requête Mediations_toutes_Selection_periode) : DEMANDEURS (NO_DEM, PART2ALLOC) MEDIATION (DEMANDEUR) J'ai créé les enregistrements tels qu'ils sont dans ta base (0,1,2,3,4,5) et écrit exactement la même requête que la tienne (Regime_allocations_part2_CMSA), sansla condition IFNULL. Avec Firebird donc, la requête me rend bien un enregistrement (au contraire de OOo Base qui ne rend rien) dans lequel : PART2ALLOC a la valeur NULL : normal et NOMBRE2 est également NULL ! Et là ça me déstabilise :-) et j'en perds mon SQL ! car je pensais bien trouver 0 ! Ca veut dire que dans ce cas-là ta requête avec la condition IFNULL fonctionnerait. Je n'ai pour l'instant pu tester ça avec Firebird car cette condition IFNULL n'existe pas, il faudrait que je trouve l'équivalent. Ceci dit, il y a quand même un petit problème dans Base parce que on devrait quand même obtenir un enregistrement : - soit (NULL, 0), - soit (NULL , NULL). Le 22/04/2010 10:24, Marie-Pierre CORONEL a écrit : 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, ribotbrib...@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 - To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org For additional commands, e-mail: users-h...@fr.openoffice.org
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Le 22/04/2010 11:00, ribotb a écrit : Ceci dit, il y a quand même un petit problème dans Base parce que on devrait quand même obtenir un enregistrement : - soit (NULL, 0), - soit (NULL , NULL). Je dirais plutôt que c'est dans Hsqldb, le moteur de Base, non ? Et après tout, est-ce si illogique que cela qu'une requête ne ressortant aucun résultat ne renvoie rien, plutôt que de renvoyer des champs null ? (certes, le comportement n'arrange pas dans le cas de Marie-Pierre mais il ne s'agit que d'une situation spécifique). A+ - To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org For additional commands, e-mail: users-h...@fr.openoffice.org
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
D'accord pour la précision : il y aurait quelque chose dans HSQLDB; parler de Base était un raccourci hâtif. Par contre il me parait normal d'avoir au moins un tuple, il faut pouvoir récupérer la valeur (attendue et qu'on n'arrive pas à avoir pour l'instant ! ), je veuxdire 0. D'ailleurs mon SGBDR Firebird me rend bien un tuple (NULL , NULL) bien que j'aurais préféré (NULL , 0 ). Je suis en train d'essayer de récupérer 0 avec la condition COALESCE (IFNULL est inconnu dans le SQL Firebird). Le 22/04/2010 11:15, Docgranville a écrit : Le 22/04/2010 11:00, ribotb a écrit : Ceci dit, il y a quand même un petit problème dans Base parce que on devrait quand même obtenir un enregistrement : - soit (NULL, 0), - soit (NULL , NULL). Je dirais plutôt que c'est dans Hsqldb, le moteur de Base, non ? Et après tout, est-ce si illogique que cela qu'une requête ne ressortant aucun résultat ne renvoie rien, plutôt que de renvoyer des champs null ? (certes, le comportement n'arrange pas dans le cas de Marie-Pierre mais il ne s'agit que d'une situation spécifique). 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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Tu as peut-être ISNULL toi, qui fonctionne à peu près pareil il me semble mais n'existe pas dans toutes les versions sql (comme ifnull). Sinon, j'avais essayé coalesce aussi, mais ça ne changeait rien à mon problème. Le 22 avril 2010 11:40, ribotb rib...@gmail.com a écrit : D'accord pour la précision : il y aurait quelque chose dans HSQLDB; parler de Base était un raccourci hâtif. Par contre il me parait normal d'avoir au moins un tuple, il faut pouvoir récupérer la valeur (attendue et qu'on n'arrive pas à avoir pour l'instant ! ), je veuxdire 0. D'ailleurs mon SGBDR Firebird me rend bien un tuple (NULL , NULL) bien que j'aurais préféré (NULL , 0 ). Je suis en train d'essayer de récupérer 0 avec la condition COALESCE (IFNULL est inconnu dans le SQL Firebird). Le 22/04/2010 11:15, Docgranville a écrit : Le 22/04/2010 11:00, ribotb a écrit : Ceci dit, il y a quand même un petit problème dans Base parce que on devrait quand même obtenir un enregistrement : - soit (NULL, 0), - soit (NULL , NULL). Je dirais plutôt que c'est dans Hsqldb, le moteur de Base, non ? Et après tout, est-ce si illogique que cela qu'une requête ne ressortant aucun résultat ne renvoie rien, plutôt que de renvoyer des champs null ? (certes, le comportement n'arrange pas dans le cas de Marie-Pierre mais il ne s'agit que d'une situation spécifique). 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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
A y regarder de près, il me semble qu'il y a une erreur dans la syntaxe de la requête Regime_allocations_part2_CMSA, dans la partie IFNULL. La syntaxe de la fonction IFNULL est : IFNULL(expression-1, expression-2). où expression-1 : COUNT ( Demandeurs.part2alloc) et expression-2 : 0 et IFNULL retourne la 1ère expression nonnull Si COUNT(...) est NULL, on veut récupérer 0 Donc il faut écrire : IFNULL (COUNT ( Demandeurs.part2alloc) , 0) au lieu de : COUNT( IFNULL( Demandeurs.part2alloc, 0 ) ) comme écrit dans la requête. Ceci dit, ça ne change rien pour l'instant vu que HSQL ne nous rend pas le tuple (NULL , NULL) qui permettrait d'appliquer la fonction IFNULL sur NOMBRE2. Le 22/04/2010 11:33, Marie-Pierre CORONEL a écrit : En fait ce qui serait normal, c'est que le résultat de COUNT étant de type integer, le résultat soit 0 :D et que la grille soit quand même créée avec résultat 0 puisque le champ groupe existe et pouvait en l'occurence afficher 1. J'avais bien repéré que la grille n'était pas créée (mon observation équivalente à tes tuples) et ça avait contribué à me conforter dans l'idée que pour COUNT 0=null Mais bon, au moins j'ai appris avec ce problème de résultats à créer des vues, à utiliser ifnull et même casewhen... Je frémis à l'idée que j'aurais pu m'appuyer sur mon premier résultat qui fonctionnait parce que tous les champs avaient au moins une occurence, et que je découvre en janvier prochain (le moment où on sortira ce formulaire) que les résultats calculés sont faux... Le 22 avril 2010 11:15, Docgranvilledocgranvi...@aol.com a écrit : Le 22/04/2010 11:00, ribotb a écrit : Ceci dit, il y a quand même un petit problème dans Base parce que on devrait quand même obtenir un enregistrement : - soit (NULL, 0), - soit (NULL , NULL). Je dirais plutôt que c'est dans Hsqldb, le moteur de Base, non ? Et après tout, est-ce si illogique que cela qu'une requête ne ressortant aucun résultat ne renvoie rien, plutôt que de renvoyer des champs null ? (certes, le comportement n'arrange pas dans le cas de Marie-Pierre mais il ne s'agit que d'une situation spécifique). 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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
j'avais essayé cette imbrication (comme pas mal d'autres d'ailleurs) et rien ne fonctionnait pour la raison que tu évoques à la fin de ton message. Le 22 avril 2010 12:20, ribotb rib...@gmail.com a écrit : A y regarder de près, il me semble qu'il y a une erreur dans la syntaxe de la requête Regime_allocations_part2_CMSA, dans la partie IFNULL. La syntaxe de la fonction IFNULL est : IFNULL(expression-1, expression-2). où expression-1 : COUNT ( Demandeurs.part2alloc) et expression-2 : 0 et IFNULL retourne la 1ère expression nonnull Si COUNT(...) est NULL, on veut récupérer 0 Donc il faut écrire : IFNULL (COUNT ( Demandeurs.part2alloc) , 0) au lieu de : COUNT( IFNULL( Demandeurs.part2alloc, 0 ) ) comme écrit dans la requête. Ceci dit, ça ne change rien pour l'instant vu que HSQL ne nous rend pas le tuple (NULL , NULL) qui permettrait d'appliquer la fonction IFNULL sur NOMBRE2. Le 22/04/2010 11:33, Marie-Pierre CORONEL a écrit : En fait ce qui serait normal, c'est que le résultat de COUNT étant de type integer, le résultat soit 0 :D et que la grille soit quand même créée avec résultat 0 puisque le champ groupe existe et pouvait en l'occurence afficher 1. J'avais bien repéré que la grille n'était pas créée (mon observation équivalente à tes tuples) et ça avait contribué à me conforter dans l'idée que pour COUNT 0=null Mais bon, au moins j'ai appris avec ce problème de résultats à créer des vues, à utiliser ifnull et même casewhen... Je frémis à l'idée que j'aurais pu m'appuyer sur mon premier résultat qui fonctionnait parce que tous les champs avaient au moins une occurence, et que je découvre en janvier prochain (le moment où on sortira ce formulaire) que les résultats calculés sont faux... Le 22 avril 2010 11:15, Docgranvilledocgranvi...@aol.com a écrit : Le 22/04/2010 11:00, ribotb a écrit : Ceci dit, il y a quand même un petit problème dans Base parce que on devrait quand même obtenir un enregistrement : - soit (NULL, 0), - soit (NULL , NULL). Je dirais plutôt que c'est dans Hsqldb, le moteur de Base, non ? Et après tout, est-ce si illogique que cela qu'une requête ne ressortant aucun résultat ne renvoie rien, plutôt que de renvoyer des champs null ? (certes, le comportement n'arrange pas dans le cas de Marie-Pierre mais il ne s'agit que d'une situation spécifique). 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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
bon ben là j'ai un gros problème en prime... j'essaye de créer le second formulaire et OOo n'arrête pas de se fermer maintenant... Le 22 avril 2010 13:08, Marie-Pierre CORONEL mariepierre@gmail.com a écrit : j'avais essayé cette imbrication (comme pas mal d'autres d'ailleurs) et rien ne fonctionnait pour la raison que tu évoques à la fin de ton message. Le 22 avril 2010 12:20, ribotb rib...@gmail.com a écrit : A y regarder de près, il me semble qu'il y a une erreur dans la syntaxe de la requête Regime_allocations_part2_CMSA, dans la partie IFNULL. La syntaxe de la fonction IFNULL est : IFNULL(expression-1, expression-2). où expression-1 : COUNT ( Demandeurs.part2alloc) et expression-2 : 0 et IFNULL retourne la 1ère expression nonnull Si COUNT(...) est NULL, on veut récupérer 0 Donc il faut écrire : IFNULL (COUNT ( Demandeurs.part2alloc) , 0) au lieu de : COUNT( IFNULL( Demandeurs.part2alloc, 0 ) ) comme écrit dans la requête. Ceci dit, ça ne change rien pour l'instant vu que HSQL ne nous rend pas le tuple (NULL , NULL) qui permettrait d'appliquer la fonction IFNULL sur NOMBRE2. Le 22/04/2010 11:33, Marie-Pierre CORONEL a écrit : En fait ce qui serait normal, c'est que le résultat de COUNT étant de type integer, le résultat soit 0 :D et que la grille soit quand même créée avec résultat 0 puisque le champ groupe existe et pouvait en l'occurence afficher 1. J'avais bien repéré que la grille n'était pas créée (mon observation équivalente à tes tuples) et ça avait contribué à me conforter dans l'idée que pour COUNT 0=null Mais bon, au moins j'ai appris avec ce problème de résultats à créer des vues, à utiliser ifnull et même casewhen... Je frémis à l'idée que j'aurais pu m'appuyer sur mon premier résultat qui fonctionnait parce que tous les champs avaient au moins une occurence, et que je découvre en janvier prochain (le moment où on sortira ce formulaire) que les résultats calculés sont faux... Le 22 avril 2010 11:15, Docgranvilledocgranvi...@aol.com a écrit : Le 22/04/2010 11:00, ribotb a écrit : Ceci dit, il y a quand même un petit problème dans Base parce que on devrait quand même obtenir un enregistrement : - soit (NULL, 0), - soit (NULL , NULL). Je dirais plutôt que c'est dans Hsqldb, le moteur de Base, non ? Et après tout, est-ce si illogique que cela qu'une requête ne ressortant aucun résultat ne renvoie rien, plutôt que de renvoyer des champs null ? (certes, le comportement n'arrange pas dans le cas de Marie-Pierre mais il ne s'agit que d'une situation spécifique). 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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Il me fait ça quelquefois au bout d'un moment et j'ai mis ça sur le compte d'un manque de RAM de mon PC. Je reboote et tout rentre dans l'ordre. Bon après-midi, Bernard Le 22/04/2010 14:09, Marie-Pierre CORONEL a écrit : bon ben là j'ai un gros problème en prime... j'essaye de créer le second formulaire et OOo n'arrête pas de se fermer maintenant... Le 22 avril 2010 13:08, Marie-Pierre CORONEL mariepierre@gmail.com a écrit : j'avais essayé cette imbrication (comme pas mal d'autres d'ailleurs) et rien ne fonctionnait pour la raison que tu évoques à la fin de ton message. Le 22 avril 2010 12:20, ribotbrib...@gmail.com a écrit : A y regarder de près, il me semble qu'il y a une erreur dans la syntaxe de la requête Regime_allocations_part2_CMSA, dans la partie IFNULL. La syntaxe de la fonction IFNULL est : IFNULL(expression-1, expression-2). où expression-1 : COUNT ( Demandeurs.part2alloc) et expression-2 : 0 et IFNULL retourne la 1ère expression nonnull Si COUNT(...) est NULL, on veut récupérer 0 Donc il faut écrire : IFNULL (COUNT ( Demandeurs.part2alloc) , 0) au lieu de : COUNT( IFNULL( Demandeurs.part2alloc, 0 ) ) comme écrit dans la requête. Ceci dit, ça ne change rien pour l'instant vu que HSQL ne nous rend pas le tuple (NULL , NULL) qui permettrait d'appliquer la fonction IFNULL sur NOMBRE2. Le 22/04/2010 11:33, Marie-Pierre CORONEL a écrit : En fait ce qui serait normal, c'est que le résultat de COUNT étant de type integer, le résultat soit 0 :D et que la grille soit quand même créée avec résultat 0 puisque le champ groupe existe et pouvait en l'occurence afficher 1. J'avais bien repéré que la grille n'était pas créée (mon observation équivalente à tes tuples) et ça avait contribué à me conforter dans l'idée que pour COUNT 0=null Mais bon, au moins j'ai appris avec ce problème de résultats à créer des vues, à utiliser ifnull et même casewhen... Je frémis à l'idée que j'aurais pu m'appuyer sur mon premier résultat qui fonctionnait parce que tous les champs avaient au moins une occurence, et que je découvre en janvier prochain (le moment où on sortira ce formulaire) que les résultats calculés sont faux... Le 22 avril 2010 11:15, Docgranvilledocgranvi...@aol.coma écrit : Le 22/04/2010 11:00, ribotb a écrit : Ceci dit, il y a quand même un petit problème dans Base parce que on devrait quand même obtenir un enregistrement : - soit (NULL, 0), - soit (NULL , NULL). Je dirais plutôt que c'est dans Hsqldb, le moteur de Base, non ? Et après tout, est-ce si illogique que cela qu'une requête ne ressortant aucun résultat ne renvoie rien, plutôt que de renvoyer des champs null ? (certes, le comportement n'arrange pas dans le cas de Marie-Pierre mais il ne s'agit que d'une situation spécifique). 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 - To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org For additional commands, e-mail: users-h...@fr.openoffice.org
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Marie-Pierre CORONEL a écrit : bon ben là j'ai un gros problème en prime... j'essaye de créer le second formulaire et OOo n'arrête pas de se fermer maintenant... Les modifications fréquentes peuvent augmenter artificiellement le poids de la base, et dans ces cas là il est conseillé, en mode SQL directe de la compacter comme décrit ici : http://user.services.openoffice.org/fr/forum/viewtopic.php?f=9t=1543p=106759hilit=defrag#p106759 et là le résultat : http://user.services.openoffice.org/fr/forum/viewtopic.php?f=9t=22184p=120335hilit=defrag#p120335 J.M - To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org For additional commands, e-mail: users-h...@fr.openoffice.org
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
je crois que ce sont les champs alloc qui se vengent de toutes les tortures que je leur fait subir depuis 2 jours, parce que le logiciel a cessé de se fermer quand je suis passée au sous-formulaire suivant qui ne les contient pas -_- les champs ont-ils une âme ? :D bon, mais je vais suivre les liens là oui, ça peut toujours remettre quelques trucs en ordre. Merci :) Le 22 avril 2010 14:53, Jean Michel PIERRE jmpni...@orange.fr a écrit : Marie-Pierre CORONEL a écrit : bon ben là j'ai un gros problème en prime... j'essaye de créer le second formulaire et OOo n'arrête pas de se fermer maintenant... Les modifications fréquentes peuvent augmenter artificiellement le poids de la base, et dans ces cas là il est conseillé, en mode SQL directe de la compacter comme décrit ici : http://user.services.openoffice.org/fr/forum/viewtopic.php?f=9t=1543p=106759hilit=defrag#p106759 et là le résultat : http://user.services.openoffice.org/fr/forum/viewtopic.php?f=9t=22184p=120335hilit=defrag#p120335 J.M - 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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Le 21/04/2010 19:11, Marie-Pierre CORONEL a écrit : re bonjour, non non, je ne tiens pas à traiter les 3 régimes différemment, j'avais essayé d'obtenir les calculs sur les 3 d'un coup mais je n'obtenais jamais un chiffre juste -_- La seule fois où j'ai enfin obtenu un chiffre juste c'est avec le système des 3 requêtes sauf quand j'ai testé avec 0 occurence. Là je suis rentrée chez moi, mais je regarderai tes requêtes demain. Je veux bien qu'on discute de la rigidité de ma base, parce que j'ai essayé de faire le plus pérenne possible et donc le contraire :'( mais bon... a+ Re-Bonjour Marie-Pierre, Bon, vu que tu as l'air d'avoir beaucoup bossé sur ce truc et que la pérennité de la base (ainsi que sa fonctionnalité) est une composante essentielle, je crois utile, avant que tu ne continues à travailler sur tes requêtes de te proposer une petite pause réflexion sur la structure de ta base elle-même. Tout d'abord sur un plan général, je ne sais pas s'il est véritablement conseillé d'utiliser Base en production ; c'est un module de OOo qui comporte encore beaucoup d'imperfections et il me semble avoir lu en plusieurs endroits (y compris sur ces liste, y compris par des membres du projet) qu'il n'était pas trop conseillé d'utiliser ce module dans un cadre professionnel ; je ne sais pas si une telle solution éliminerait tout ou partie des risques (en vertu desquels la prudence est souvent recommandée à l'égard de Base) mais, pour rester dans le libre, peut-être pourrais-tu créer cette base avec Mysql et t'y connecter avec Base (tes formulaires fonctionneront et tu pourras créer des requêtes sans aucune difficulté, mais en revanche, je pense que tu ne pourras pas apporter de modifications à la structure de tes tables avec Base, et à chaque fois que tu voudras le faire, il te faudra passer par Mysql) ; qui plus est, Hsqldb ne gère pas les bases multi-utilisateurs et ça peut avoir une influence sur l'utilisation de ta base de données. En ce qui concerne ta base elle-même, j'ai compris qu'elle allait servir à gérer le suivi d'un service de médiation, certaines étant civiles, d'autres étant pénales. La première question que je me pose, c'est pourquoi enregistrer dans deux tables différentes, les médiations civiles et les médiations pénales ? Ça t'oblige ensuite à dupliquer plein de tables comme, par exemple, les tables Aide mémoire alors qu'elles ont la même structure ; mieux encore, les tables relatives aux liens entre les parties, qui regroupent le même type d'informations (même si je suis conscient que certains types de liens ne seront utiles -ou ne devront être utilisables- que dans tel type de médiation et pas dans l'autre). C'est en cela que je pense que ta base est un peu trop rigide. En y réfléchissant comme ça, au débotté, je me dis que les caractéristiques sont les suivantes : le service concerné est saisi d'une médiation ; il s'agit d'une procédure qui peut disposer de deux natures différentes, provenir de plusieurs sources et devra faire l'objet d'un suivi ; elle concerne, généralement deux ou plusieurs personnes. Du coup, je serais tenté de me dire que j'ai besoin de trois tables initiales : - une table regroupant toutes les médiations dont le service a été saisi et contenant leurs caractéristiques (origine, nature,...) - une table regroupant les personnes concernées avec tous les renseignements les concernant ; - une table regroupant les informations relatives au suivi (les évènements se déroulant dans le cadre de la médiation). Ces trois tables là vont être les tables principales de ma base puisque ce sont elles qui vont évoluer tous les jours. Viennent ensuite les tables que je qualifierais de secondaires ou de utilitaires ; en fait, ce sont les tables dans lesquelles seront stockées des données récurrentes (les liens entre les parties par exemple, le mode de connaissance, les modalités de saisine du service, les suites réservées,...). Ensuite, tu peux faire des requêtes (avec leurs vues et leurs formulaires associés) pour obtenir un regard limité à telle ou telle portion de ta base (un formulaire uniquement dédié à la consultation et ne regroupant que les médiations civiles et un autre pour les pénales). L'une des choses qui me gênent un peu dans ta base, telle qu'elle est actuellement conçue, c'est que, par exemple, pour les demandeurs, la partie 1 et la partie 2 figurent dans le même enregistrement mais que l'on renseigne exactement les mêmes informations pour chacune des parties ; pour ma part, j'aurais tendance à faire figurer dans cette table qu'un seul champ nom, un seul champ prénom, etc... ; la clef primaire servirait alors, dans la table relatives aux médiations de clef externe, permettant d'identifier le statut de partie 1 ou de partie 2 de chaque personne ; et que fais-tu si un jour tu as une médiation avec 3 parties ? Pour résumer je séparerais d'un côté les procédures (et leurs caractéristiques) et de
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Il y a aussi SHUTDOWN COMPACT qui réduit les fichiers à leur taille minimum avant de fermer la base (Outils SQL). Bernard Le 22/04/2010 14:53, Jean Michel PIERRE a écrit : Marie-Pierre CORONEL a écrit : bon ben là j'ai un gros problème en prime... j'essaye de créer le second formulaire et OOo n'arrête pas de se fermer maintenant... Les modifications fréquentes peuvent augmenter artificiellement le poids de la base, et dans ces cas là il est conseillé, en mode SQL directe de la compacter comme décrit ici : http://user.services.openoffice.org/fr/forum/viewtopic.php?f=9t=1543p=106759hilit=defrag#p106759 et là le résultat : http://user.services.openoffice.org/fr/forum/viewtopic.php?f=9t=22184p=120335hilit=defrag#p120335 J.M - 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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
re :) bon alors, ma réponse risque d'être tout aussi longue :D je vais commencer par te présenter mon contexte, ça t'apportera déjà quelques réponses je pense. - Ma structure : une petite structure qui n'a pas les moyens d'avoir un développeur, qui dépend de la mairie pour l'informatique, laquelle n'a qu'un développeur qui par ailleurs est le chef du service et donc n'a aucun temps à nous consacrer. Peu d'argent aussi, d'autant que travaillant dans le social, tout ce qu'on consacre à autre chose que du social nous fend le coeur. - Des services en difficulté, de plus en plus de stats demandées, de moins en moins de personnel, même si les dossiers ne sont pas très nombreux (pour la médiation c'est à peu près 200 par an) les collègues ont toujours plus de mal à les produire (pour le service de médiation, demandées début janvier on les aura enfin fin mars, après plusieurs aller-retour liés aux insuffisances de la production, des statistiques bâclées et non contrôlées où les incohérences sautent au visage, simplement parce que la collègue a le plus grand mal à les intégrer dans son plan de charge) - Moi ex-programmeur de gestion, qui n'a pas vu une ligne de programme depuis 15 ans, n'a pas entretenu la moindre connaissance sur le sujet, la page était tournée, responsable des finances, puis responsable du personnel maintenant chargée de mission auprès de la direction, théoriquement affectée à l'élaboration de projet, je me sentais tellement concernée par base que je ne me suis même pas inscrite à la formation de migration... Alors, tu me dis que je devrais travailler sur Mysql par l'intermédiaire d'OOo, tu as sûrement raison, le truc c'est que je ne sais même pas comment on fait... Aujourd'hui, je suis clairement non-programmeur, la base doit fonctionner sans recours aux macros et surtout, je n'ai pas vocation à l'entretenir, c'est pour ça que je disais avoir cherché à la faire la plus pérenne possible (notamment, j'ai préféré les tables utilitaires aux listes de valeur, même quand il n'y avait que 2 ou 3 valeurs, sauf pour monsieur et madame) J'ai lu en effet comme toi l'avertissement notamment de Sophie sur le fait que Base était orienté mono utilisateur et que Sun (à l'époque) ne s'engageait pas sur autre chose, qu'il était donc déconseillé de l'utiliser en production. Mais avons-nous vraiment le choix quand nous sommes une petite structure sans informaticien et relativement peu de moyens ? Au passage, la base que je monte ne sera rien d'autre que mono-utilisateur, nous n'avons qu'une médiatrice et à mi-temps seulement (sauf pendant la période où on la partagera pour les éventuelles modifications à réaliser si mes tests n'ont pas été suffisants et j'ai déjà prévu qu'on s'entendrait sur les jours de la semaine). - Les partenaires de la médiation : il fut un temps (heureux) où il n'y avait que la justice qui ne demandait pas grand chose et le CCAS qui en demandait nettement plus. Mais en 2009 arrivée de la CAF, qui tâtonne, veut des infos puisque maintenant pour la médiation civile c'est surtout elle qui paye, décide par exemple qu'il faut 3 natures juridiques pour les entretiens d'info et deux seulement pour les médiations (les deux dernières pour les infos étant regroupées dans la dernière pour les médiations), nous crée en mars 2010 des infos collectives dont il n'avait jamais été question jusque là, mais qu'on devra dénombrer pour l'activité 2010. Mais même la justice n'est pas totalement d'accord avec elle-même selon qu'on a à faire au Procureur (médiations pénales) ou au Greffe du TGI, on ne nous demande pas tout à fait les mêmes renseignements (même si tu as eu le sentiment du contraire, il y a une ou deux variantes qui m'ont en effet obligée à démultiplier le nombre de tables). Là-dessus tu ajoutes les demandes CCAS qui sont parfois sur les mêmes domaines mais classifient différemment, et la vision du médiateur de sa propre activité... et ça donne ce que j'ai monté (notamment sur les résultats, j'ai composé avec les demandes des uns et des autres) :D - Sur la base elle-même : * En fait la table demandeurs est mal nommée. Je m'en suis rendu compte un peu tard, j'ai hésité à la renommer, (mais j'aurais eu tellement à reprendre...), elle devrait s'appeler conflit ou parties au conflit (parce que médiation est déjà pris par une autre table). Il faut concevoir que notre médiatrice ne connaît les individus qu'à travers leur conflit. Ma collègue, si elle a besoin de trouver des renseignements sur quelqu'un actuellement va chercher dans la chemise de la médiation correspondante, elle n'a pas une fiche par personne. Les individus ne sont pas repérés, ce sont les médiations qui le sont. J'ai pensé à la table que tu proposes, c'est comme ça que cette table se retrouve mal nommée, mais ça n'est pas adéquat. Il lui faudrait attribuer un n° à un individu qui ne peut en tout état de cause pas être convoqué seul par exemple. Jamais elle n'appellera une fiche qui ne concerne que l'une des deux parties (enfin...
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
bah avec Defrag ma base a maigri de 6 ko :D alors je ne pense pas utiliser ta commande, mais merci pour l'info :) Le 22 avril 2010 20:10, ribotb rib...@gmail.com a écrit : Il y a aussi SHUTDOWN COMPACT qui réduit les fichiers à leur taille minimum avant de fermer la base (Outils SQL). Bernard Le 22/04/2010 14:53, Jean Michel PIERRE a écrit : Marie-Pierre CORONEL a écrit : bon ben là j'ai un gros problème en prime... j'essaye de créer le second formulaire et OOo n'arrête pas de se fermer maintenant... Les modifications fréquentes peuvent augmenter artificiellement le poids de la base, et dans ces cas là il est conseillé, en mode SQL directe de la compacter comme décrit ici : http://user.services.openoffice.org/fr/forum/viewtopic.php?f=9t=1543p=106759hilit=defrag#p106759 et là le résultat : http://user.services.openoffice.org/fr/forum/viewtopic.php?f=9t=22184p=120335hilit=defrag#p120335 J.M - 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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Le 21/04/2010 15:38, Marie-Pierre CORONEL a écrit : Bonjour, j'ai déjà mis un message sur le forum à ce sujet, mais comme je crois qu'il y a ici des gens qui ne vont pas sur le forum, peut-être passera-t-il quelqu'un qui ait une réponse pour moi... j'essaie d'additionner dans une requête deux champs issus de deux autres requêtes calculés avec COUNT. Mes 3 requêtes ensemble fonctionnent très bien dès lors que le résultat des COUNT est au moins égal à 1. COUNT apparemment ne connaît pas 0. J'ai donc cru que le résultat de COUNT était null mais... il semble que non. J'ai essayé IFNULL, COALESCE, CASEWHEN (qui n'accepte pas expression is null, pas réussi à faire une syntaxe qui fonctionne avec CASE WHEN), d'utiliser des vues à partir de mes 2 requêtes, rien ne fonctionne. Le résultat de COUNT quand il n'y a pas d'occurence c'est rien ? Donc l'opération que je cherche à faire serait infaisable ? Merci d'avance. Bonjour Marie-Pierre, J'ai un peu de mal à suivre ta démarche, à la lecture de ta description ; te serait-il possible de donner un lien vers ta base (si elle n'est pas confidentielle bien sûr) ? On est bien d'accord que les résultats de tes 2 premières requêtes sont stockés dans une vue pour que tu puisse les utiliser dans la 3ème ? A+ - To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org For additional commands, e-mail: users-h...@fr.openoffice.org
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Alors, voilà ma base qui n'est pas encore confidentielle, les exemples qu'elle comporte sont bidons. http://www.cijoint.fr/cjlink.php?file=cj201004/cijtWcP6UI.odb comme tu vas le voir il y a déjà beaucoup de requêtes tu peux voir les requêtes initiales (qui fonctionnent quand les 2 champs comportent au moins une occurence avec les requêtes : Regime_allocations_partie1_CAF, Regime_allocations_part2_CAF et Regime_allocations_total_CAF elles n'utilisent pas de vue. tous mes tests ont été faits sur les mêmes mais CMSA (qui ne sont peut-être plus dans un état très uniforme d'ailleurs maintenant...) et ensuite avec les 2 vues que tu peux trouver sous les noms regimeCMSApart1 et regimeCMSApart2 sauf pour coalesce. si pour compléter ton idée tu as besoin de savoir à quoi elles servent, tu peux regarder dans le formulaire 9-pour remplir le formulaire d'activité type 2010, ce sont les 4 derniers items de la colonne de gauche. j'espère n'avoir rien oublié :) Le 21 avril 2010 16:08, Docgranville docgranvi...@aol.com a écrit : Le 21/04/2010 15:38, Marie-Pierre CORONEL a écrit : Bonjour, j'ai déjà mis un message sur le forum à ce sujet, mais comme je crois qu'il y a ici des gens qui ne vont pas sur le forum, peut-être passera-t-il quelqu'un qui ait une réponse pour moi... j'essaie d'additionner dans une requête deux champs issus de deux autres requêtes calculés avec COUNT. Mes 3 requêtes ensemble fonctionnent très bien dès lors que le résultat des COUNT est au moins égal à 1. COUNT apparemment ne connaît pas 0. J'ai donc cru que le résultat de COUNT était null mais... il semble que non. J'ai essayé IFNULL, COALESCE, CASEWHEN (qui n'accepte pas expression is null, pas réussi à faire une syntaxe qui fonctionne avec CASE WHEN), d'utiliser des vues à partir de mes 2 requêtes, rien ne fonctionne. Le résultat de COUNT quand il n'y a pas d'occurence c'est rien ? Donc l'opération que je cherche à faire serait infaisable ? Merci d'avance. Bonjour Marie-Pierre, J'ai un peu de mal à suivre ta démarche, à la lecture de ta description ; te serait-il possible de donner un lien vers ta base (si elle n'est pas confidentielle bien sûr) ? On est bien d'accord que les résultats de tes 2 premières requêtes sont stockés dans une vue pour que tu puisse les utiliser dans la 3ème ? 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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
hum j'ai voulu faire du ménage dans ci-joint... et j'ai supprimé le mauvais fichier... nouveau lien http://www.cijoint.fr/cjlink.php?file=cj201004/cijMs7dYvM.odb Le 21 avril 2010 17:12, Marie-Pierre CORONEL mariepierre@gmail.com a écrit : Alors, voilà ma base qui n'est pas encore confidentielle, les exemples qu'elle comporte sont bidons. http://www.cijoint.fr/cjlink.php?file=cj201004/cijtWcP6UI.odb comme tu vas le voir il y a déjà beaucoup de requêtes tu peux voir les requêtes initiales (qui fonctionnent quand les 2 champs comportent au moins une occurence avec les requêtes : Regime_allocations_partie1_CAF, Regime_allocations_part2_CAF et Regime_allocations_total_CAF elles n'utilisent pas de vue. tous mes tests ont été faits sur les mêmes mais CMSA (qui ne sont peut-être plus dans un état très uniforme d'ailleurs maintenant...) et ensuite avec les 2 vues que tu peux trouver sous les noms regimeCMSApart1 et regimeCMSApart2 sauf pour coalesce. si pour compléter ton idée tu as besoin de savoir à quoi elles servent, tu peux regarder dans le formulaire 9-pour remplir le formulaire d'activité type 2010, ce sont les 4 derniers items de la colonne de gauche. j'espère n'avoir rien oublié :) Le 21 avril 2010 16:08, Docgranville docgranvi...@aol.com a écrit : Le 21/04/2010 15:38, Marie-Pierre CORONEL a écrit : Bonjour, j'ai déjà mis un message sur le forum à ce sujet, mais comme je crois qu'il y a ici des gens qui ne vont pas sur le forum, peut-être passera-t-il quelqu'un qui ait une réponse pour moi... j'essaie d'additionner dans une requête deux champs issus de deux autres requêtes calculés avec COUNT. Mes 3 requêtes ensemble fonctionnent très bien dès lors que le résultat des COUNT est au moins égal à 1. COUNT apparemment ne connaît pas 0. J'ai donc cru que le résultat de COUNT était null mais... il semble que non. J'ai essayé IFNULL, COALESCE, CASEWHEN (qui n'accepte pas expression is null, pas réussi à faire une syntaxe qui fonctionne avec CASE WHEN), d'utiliser des vues à partir de mes 2 requêtes, rien ne fonctionne. Le résultat de COUNT quand il n'y a pas d'occurence c'est rien ? Donc l'opération que je cherche à faire serait infaisable ? Merci d'avance. Bonjour Marie-Pierre, J'ai un peu de mal à suivre ta démarche, à la lecture de ta description ; te serait-il possible de donner un lien vers ta base (si elle n'est pas confidentielle bien sûr) ? On est bien d'accord que les résultats de tes 2 premières requêtes sont stockés dans une vue pour que tu puisse les utiliser dans la 3ème ? 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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Le 21/04/2010 18:04, Marie-Pierre CORONEL a écrit : hum j'ai voulu faire du ménage dans ci-joint... et j'ai supprimé le mauvais fichier... nouveau lien http://www.cijoint.fr/cjlink.php?file=cj201004/cijMs7dYvM.odb Re-bonjour Marie-Pierre, J'ai jeté un coup d'oeil rapide sur ta base ; peut-être aurais-je (à l'occasion) quelques réflexions à te faire partager sur sa conception qui me semble un peu trop complexe (ou rigide si tu préfères). En ce qui concerne ton problème particulier, je n'en connais pas véritablement la solution mais je pense (c'est déjà quelque chose) en connaître l'origine ; en réalité, je pense que le souci vient du fait que ta requête porte sur une table vide ( plus précisément sur une vue vide, celle générée par la Regime_allocations_part2_CMSA) ; la clause ifnull permet de sauter un champ null dans un enregistrement mais, en l'occurrence, il n'y a carrément pas d'enregistrement (puisqu'aucun enregistrement de la table demandeurs ne correspond aux critères fixés dans cette fameuse requête Regime_allocations_part2_CMSA. Pour éviter ça, je me suis dit que, peut-être, tu pourrais faire une requête (et éventuellement une vue) synthétisant, sur la période requise, le nombre d'allocataires de type part1 pour chaque code d'allocation ; ta requête Regime_allocation_partie1_CMSA deviendrait : SELECT COUNT( Demandeurs.part1alloc ) AS nombre1, Demandeurs.part1alloc FROM Mediations_toutes_Selection_periode, Demandeurs WHERE Mediations_toutes_Selection_periode.demandeurs = Demandeurs.no_demandeurs GROUP BY Demandeurs.part1alloc (en fait, je n'ai supprimé que la clause HAVING) Si on fait la même chose sur ta requête Regime_allocation_partie2_CMSA, elle devient : SELECT Demandeurs.part2alloc, COUNT( IFNULL( Demandeurs.part2alloc, 0 ) ) AS nombre2 FROM Mediations_toutes_Selection_periode, Demandeurs WHERE Mediations_toutes_Selection_periode.demandeurs = Demandeurs.no_demandeurs GROUP BY Demandeurs.part2alloc (ici aussi, donc, siplement suppression de la clause HAVING). Avec ces requêtes, on obtient un tableau regroupant, pour chaque code d'allocation, le nombre d'allocataires sur la période. La dernière requête est modifiée un peu plus en profondeur ; il s'agit de la requête Regime_allocations_CMSA_Total, qui devient : SELECT regimeCMSApart1.part1alloc, ifnull(nombre1,0) as nombre1, ifnull(nombre2,0) as nombre2, ifnull(regimeCMSApart1.nombre1,0) + ifnull(regimeCMSApart2.nombre2,0) AS Total FROM regimeCMSApart1 left join regimeCMSApart2 on regimeCMSApart1.part1alloc = regimeCMSApart2.part2alloc (attention, cette requête porte sur les vues ; il ne faut donc pas oublier de les modifier, sinon, elle sont toujours avec la clause HAVING) Tu obtiens avec ça un tableau comportant une colonne énonçant les différents types d'allocations rencontrés (ici, 0, 1 et 2), une colonne mentionnant le nombre d'allocataires partie 1 bénéficiant de ce type d'allocation (ou 0 s'il n'y en a pas mais en l'occurrence, ce n'est pas possible), un colonne mentionnant le nombre d'allocataires partie 2 bénéficiant de ce type d'allocation (ou 0, et ici c'est possible) et enfin une colonne totalisant les deux chiffres précédents. Je pense que, dans l'esprit, ça ressemble à ce que tu veux ; ensuite, si tu veux avoir une requête avec uniquement tel ou tel type d'allocation, tu peux parfaitement pointer sur cette dernière requête et en extraire nombre1 et noùmbre2 qui seront toujours renseignés (puisque le ifnull est utilisé pour créer cette requête). On pourra en re-discuter un peu plus tard si tu veux. A+ - To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org For additional commands, e-mail: users-h...@fr.openoffice.org
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
re bonjour, non non, je ne tiens pas à traiter les 3 régimes différemment, j'avais essayé d'obtenir les calculs sur les 3 d'un coup mais je n'obtenais jamais un chiffre juste -_- La seule fois où j'ai enfin obtenu un chiffre juste c'est avec le système des 3 requêtes sauf quand j'ai testé avec 0 occurence. Là je suis rentrée chez moi, mais je regarderai tes requêtes demain. Je veux bien qu'on discute de la rigidité de ma base, parce que j'ai essayé de faire le plus pérenne possible et donc le contraire :'( mais bon... a+ Le 21 avril 2010 19:04, Docgranville docgranvi...@aol.com a écrit : Le 21/04/2010 18:04, Marie-Pierre CORONEL a écrit : hum j'ai voulu faire du ménage dans ci-joint... et j'ai supprimé le mauvais fichier... nouveau lien http://www.cijoint.fr/cjlink.php?file=cj201004/cijMs7dYvM.odb Re-bonjour Marie-Pierre, J'ai jeté un coup d'oeil rapide sur ta base ; peut-être aurais-je (à l'occasion) quelques réflexions à te faire partager sur sa conception qui me semble un peu trop complexe (ou rigide si tu préfères). En ce qui concerne ton problème particulier, je n'en connais pas véritablement la solution mais je pense (c'est déjà quelque chose) en connaître l'origine ; en réalité, je pense que le souci vient du fait que ta requête porte sur une table vide ( plus précisément sur une vue vide, celle générée par la Regime_allocations_part2_CMSA) ; la clause ifnull permet de sauter un champ null dans un enregistrement mais, en l'occurrence, il n'y a carrément pas d'enregistrement (puisqu'aucun enregistrement de la table demandeurs ne correspond aux critères fixés dans cette fameuse requête Regime_allocations_part2_CMSA. Pour éviter ça, je me suis dit que, peut-être, tu pourrais faire une requête (et éventuellement une vue) synthétisant, sur la période requise, le nombre d'allocataires de type part1 pour chaque code d'allocation ; ta requête Regime_allocation_partie1_CMSA deviendrait : SELECT COUNT( Demandeurs.part1alloc ) AS nombre1, Demandeurs.part1alloc FROM Mediations_toutes_Selection_periode, Demandeurs WHERE Mediations_toutes_Selection_periode.demandeurs = Demandeurs.no_demandeurs GROUP BY Demandeurs.part1alloc (en fait, je n'ai supprimé que la clause HAVING) Si on fait la même chose sur ta requête Regime_allocation_partie2_CMSA, elle devient : SELECT Demandeurs.part2alloc, COUNT( IFNULL( Demandeurs.part2alloc, 0 ) ) AS nombre2 FROM Mediations_toutes_Selection_periode, Demandeurs WHERE Mediations_toutes_Selection_periode.demandeurs = Demandeurs.no_demandeurs GROUP BY Demandeurs.part2alloc (ici aussi, donc, siplement suppression de la clause HAVING). Avec ces requêtes, on obtient un tableau regroupant, pour chaque code d'allocation, le nombre d'allocataires sur la période. La dernière requête est modifiée un peu plus en profondeur ; il s'agit de la requête Regime_allocations_CMSA_Total, qui devient : SELECT regimeCMSApart1.part1alloc, ifnull(nombre1,0) as nombre1, ifnull(nombre2,0) as nombre2, ifnull(regimeCMSApart1.nombre1,0) + ifnull(regimeCMSApart2.nombre2,0) AS Total FROM regimeCMSApart1 left join regimeCMSApart2 on regimeCMSApart1.part1alloc = regimeCMSApart2.part2alloc (attention, cette requête porte sur les vues ; il ne faut donc pas oublier de les modifier, sinon, elle sont toujours avec la clause HAVING) Tu obtiens avec ça un tableau comportant une colonne énonçant les différents types d'allocations rencontrés (ici, 0, 1 et 2), une colonne mentionnant le nombre d'allocataires partie 1 bénéficiant de ce type d'allocation (ou 0 s'il n'y en a pas mais en l'occurrence, ce n'est pas possible), un colonne mentionnant le nombre d'allocataires partie 2 bénéficiant de ce type d'allocation (ou 0, et ici c'est possible) et enfin une colonne totalisant les deux chiffres précédents. Je pense que, dans l'esprit, ça ressemble à ce que tu veux ; ensuite, si tu veux avoir une requête avec uniquement tel ou tel type d'allocation, tu peux parfaitement pointer sur cette dernière requête et en extraire nombre1 et noùmbre2 qui seront toujours renseignés (puisque le ifnull est utilisé pour créer cette requête). On pourra en re-discuter un peu plus tard si tu veux. 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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Bonsoir Marie-Pierre, Je ne me suis pas penché sur ce problème (intéressant) mais je peux te dire en tout cas que le résultat ne peut pas être NULL. NULL n'est pas une valeur mais c'est un *état *qui indique que la valeur d'un élément est inconnue ou indéterminée. Bernard Le 21/04/2010 19:11, Marie-Pierre CORONEL a écrit : re bonjour, non non, je ne tiens pas à traiter les 3 régimes différemment, j'avais essayé d'obtenir les calculs sur les 3 d'un coup mais je n'obtenais jamais un chiffre juste -_- La seule fois où j'ai enfin obtenu un chiffre juste c'est avec le système des 3 requêtes sauf quand j'ai testé avec 0 occurence. Là je suis rentrée chez moi, mais je regarderai tes requêtes demain. Je veux bien qu'on discute de la rigidité de ma base, parce que j'ai essayé de faire le plus pérenne possible et donc le contraire :'( mais bon... a+ Le 21 avril 2010 19:04, Docgranvilledocgranvi...@aol.com a écrit : Le 21/04/2010 18:04, Marie-Pierre CORONEL a écrit : hum j'ai voulu faire du ménage dans ci-joint... et j'ai supprimé le mauvais fichier... nouveau lien http://www.cijoint.fr/cjlink.php?file=cj201004/cijMs7dYvM.odb Re-bonjour Marie-Pierre, J'ai jeté un coup d'oeil rapide sur ta base ; peut-être aurais-je (à l'occasion) quelques réflexions à te faire partager sur sa conception qui me semble un peu trop complexe (ou rigide si tu préfères). En ce qui concerne ton problème particulier, je n'en connais pas véritablement la solution mais je pense (c'est déjà quelque chose) en connaître l'origine ; en réalité, je pense que le souci vient du fait que ta requête porte sur une table vide ( plus précisément sur une vue vide, celle générée par la Regime_allocations_part2_CMSA) ; la clause ifnull permet de sauter un champ null dans un enregistrement mais, en l'occurrence, il n'y a carrément pas d'enregistrement (puisqu'aucun enregistrement de la table demandeurs ne correspond aux critères fixés dans cette fameuse requête Regime_allocations_part2_CMSA. Pour éviter ça, je me suis dit que, peut-être, tu pourrais faire une requête (et éventuellement une vue) synthétisant, sur la période requise, le nombre d'allocataires de type part1 pour chaque code d'allocation ; ta requête Regime_allocation_partie1_CMSA deviendrait : SELECT COUNT( Demandeurs.part1alloc ) AS nombre1, Demandeurs.part1alloc FROM Mediations_toutes_Selection_periode, Demandeurs WHERE Mediations_toutes_Selection_periode.demandeurs = Demandeurs.no_demandeurs GROUP BY Demandeurs.part1alloc (en fait, je n'ai supprimé que la clause HAVING) Si on fait la même chose sur ta requête Regime_allocation_partie2_CMSA, elle devient : SELECT Demandeurs.part2alloc, COUNT( IFNULL( Demandeurs.part2alloc, 0 ) ) AS nombre2 FROM Mediations_toutes_Selection_periode, Demandeurs WHERE Mediations_toutes_Selection_periode.demandeurs = Demandeurs.no_demandeurs GROUP BY Demandeurs.part2alloc (ici aussi, donc, siplement suppression de la clause HAVING). Avec ces requêtes, on obtient un tableau regroupant, pour chaque code d'allocation, le nombre d'allocataires sur la période. La dernière requête est modifiée un peu plus en profondeur ; il s'agit de la requête Regime_allocations_CMSA_Total, qui devient : SELECT regimeCMSApart1.part1alloc, ifnull(nombre1,0) as nombre1, ifnull(nombre2,0) as nombre2, ifnull(regimeCMSApart1.nombre1,0) + ifnull(regimeCMSApart2.nombre2,0) AS Total FROM regimeCMSApart1 left join regimeCMSApart2 on regimeCMSApart1.part1alloc = regimeCMSApart2.part2alloc (attention, cette requête porte sur les vues ; il ne faut donc pas oublier de les modifier, sinon, elle sont toujours avec la clause HAVING) Tu obtiens avec ça un tableau comportant une colonne énonçant les différents types d'allocations rencontrés (ici, 0, 1 et 2), une colonne mentionnant le nombre d'allocataires partie 1 bénéficiant de ce type d'allocation (ou 0 s'il n'y en a pas mais en l'occurrence, ce n'est pas possible), un colonne mentionnant le nombre d'allocataires partie 2 bénéficiant de ce type d'allocation (ou 0, et ici c'est possible) et enfin une colonne totalisant les deux chiffres précédents. Je pense que, dans l'esprit, ça ressemble à ce que tu veux ; ensuite, si tu veux avoir une requête avec uniquement tel ou tel type d'allocation, tu peux parfaitement pointer sur cette dernière requête et en extraire nombre1 et noùmbre2 qui seront toujours renseignés (puisque le ifnull est utilisé pour créer cette requête). On pourra en re-discuter un peu plus tard si tu veux. 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,
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Salut, et pourtant la solution de Docgranville passe par Ifnull (que j'ai essayé sans succès, je comprendrais sûrement demain pourquoi -_-) Le 21 avril 2010 22:30, ribotb rib...@gmail.com a écrit : Bonsoir Marie-Pierre, Je ne me suis pas penché sur ce problème (intéressant) mais je peux te dire en tout cas que le résultat ne peut pas être NULL. NULL n'est pas une valeur mais c'est un *état *qui indique que la valeur d'un élément est inconnue ou indéterminée. Bernard Le 21/04/2010 19:11, Marie-Pierre CORONEL a écrit : re bonjour, non non, je ne tiens pas à traiter les 3 régimes différemment, j'avais essayé d'obtenir les calculs sur les 3 d'un coup mais je n'obtenais jamais un chiffre juste -_- La seule fois où j'ai enfin obtenu un chiffre juste c'est avec le système des 3 requêtes sauf quand j'ai testé avec 0 occurence. Là je suis rentrée chez moi, mais je regarderai tes requêtes demain. Je veux bien qu'on discute de la rigidité de ma base, parce que j'ai essayé de faire le plus pérenne possible et donc le contraire :'( mais bon... a+ Le 21 avril 2010 19:04, Docgranvilledocgranvi...@aol.com a écrit : Le 21/04/2010 18:04, Marie-Pierre CORONEL a écrit : hum j'ai voulu faire du ménage dans ci-joint... et j'ai supprimé le mauvais fichier... nouveau lien http://www.cijoint.fr/cjlink.php?file=cj201004/cijMs7dYvM.odb Re-bonjour Marie-Pierre, J'ai jeté un coup d'oeil rapide sur ta base ; peut-être aurais-je (à l'occasion) quelques réflexions à te faire partager sur sa conception qui me semble un peu trop complexe (ou rigide si tu préfères). En ce qui concerne ton problème particulier, je n'en connais pas véritablement la solution mais je pense (c'est déjà quelque chose) en connaître l'origine ; en réalité, je pense que le souci vient du fait que ta requête porte sur une table vide ( plus précisément sur une vue vide, celle générée par la Regime_allocations_part2_CMSA) ; la clause ifnull permet de sauter un champ null dans un enregistrement mais, en l'occurrence, il n'y a carrément pas d'enregistrement (puisqu'aucun enregistrement de la table demandeurs ne correspond aux critères fixés dans cette fameuse requête Regime_allocations_part2_CMSA. Pour éviter ça, je me suis dit que, peut-être, tu pourrais faire une requête (et éventuellement une vue) synthétisant, sur la période requise, le nombre d'allocataires de type part1 pour chaque code d'allocation ; ta requête Regime_allocation_partie1_CMSA deviendrait : SELECT COUNT( Demandeurs.part1alloc ) AS nombre1, Demandeurs.part1alloc FROM Mediations_toutes_Selection_periode, Demandeurs WHERE Mediations_toutes_Selection_periode.demandeurs = Demandeurs.no_demandeurs GROUP BY Demandeurs.part1alloc (en fait, je n'ai supprimé que la clause HAVING) Si on fait la même chose sur ta requête Regime_allocation_partie2_CMSA, elle devient : SELECT Demandeurs.part2alloc, COUNT( IFNULL( Demandeurs.part2alloc, 0 ) ) AS nombre2 FROM Mediations_toutes_Selection_periode, Demandeurs WHERE Mediations_toutes_Selection_periode.demandeurs = Demandeurs.no_demandeurs GROUP BY Demandeurs.part2alloc (ici aussi, donc, siplement suppression de la clause HAVING). Avec ces requêtes, on obtient un tableau regroupant, pour chaque code d'allocation, le nombre d'allocataires sur la période. La dernière requête est modifiée un peu plus en profondeur ; il s'agit de la requête Regime_allocations_CMSA_Total, qui devient : SELECT regimeCMSApart1.part1alloc, ifnull(nombre1,0) as nombre1, ifnull(nombre2,0) as nombre2, ifnull(regimeCMSApart1.nombre1,0) + ifnull(regimeCMSApart2.nombre2,0) AS Total FROM regimeCMSApart1 left join regimeCMSApart2 on regimeCMSApart1.part1alloc = regimeCMSApart2.part2alloc (attention, cette requête porte sur les vues ; il ne faut donc pas oublier de les modifier, sinon, elle sont toujours avec la clause HAVING) Tu obtiens avec ça un tableau comportant une colonne énonçant les différents types d'allocations rencontrés (ici, 0, 1 et 2), une colonne mentionnant le nombre d'allocataires partie 1 bénéficiant de ce type d'allocation (ou 0 s'il n'y en a pas mais en l'occurrence, ce n'est pas possible), un colonne mentionnant le nombre d'allocataires partie 2 bénéficiant de ce type d'allocation (ou 0, et ici c'est possible) et enfin une colonne totalisant les deux chiffres précédents. Je pense que, dans l'esprit, ça ressemble à ce que tu veux ; ensuite, si tu veux avoir une requête avec uniquement tel ou tel type d'allocation, tu peux parfaitement pointer sur cette dernière requête et en extraire nombre1 et noùmbre2 qui seront toujours renseignés (puisque le ifnull est utilisé pour créer cette requête). On pourra en re-discuter un peu plus tard si tu veux. A+ - To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org For additional commands, e-mail: users-h...@fr.openoffice.org
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Je n'ai pas encore examiné ta base mais à te lire et à priori j'aurais dit que si les requêtes ne renvoient aucun tuple, le résultat du COUNT devrait être 0. Le 21/04/2010 22:35, Marie-Pierre CORONEL a écrit : Salut, et pourtant la solution de Docgranville passe par Ifnull (que j'ai essayé sans succès, je comprendrais sûrement demain pourquoi -_-) Le 21 avril 2010 22:30, ribotbrib...@gmail.com a écrit : Bonsoir Marie-Pierre, Je ne me suis pas penché sur ce problème (intéressant) mais je peux te dire en tout cas que le résultat ne peut pas être NULL. NULL n'est pas une valeur mais c'est un *état *qui indique que la valeur d'un élément est inconnue ou indéterminée. Bernard Le 21/04/2010 19:11, Marie-Pierre CORONEL a écrit : re bonjour, non non, je ne tiens pas à traiter les 3 régimes différemment, j'avais essayé d'obtenir les calculs sur les 3 d'un coup mais je n'obtenais jamais un chiffre juste -_- La seule fois où j'ai enfin obtenu un chiffre juste c'est avec le système des 3 requêtes sauf quand j'ai testé avec 0 occurence. Là je suis rentrée chez moi, mais je regarderai tes requêtes demain. Je veux bien qu'on discute de la rigidité de ma base, parce que j'ai essayé de faire le plus pérenne possible et donc le contraire :'( mais bon... a+ Le 21 avril 2010 19:04, Docgranvilledocgranvi...@aol.coma écrit : Le 21/04/2010 18:04, Marie-Pierre CORONEL a écrit : hum j'ai voulu faire du ménage dans ci-joint... et j'ai supprimé le mauvais fichier... nouveau lien http://www.cijoint.fr/cjlink.php?file=cj201004/cijMs7dYvM.odb Re-bonjour Marie-Pierre, J'ai jeté un coup d'oeil rapide sur ta base ; peut-être aurais-je (à l'occasion) quelques réflexions à te faire partager sur sa conception qui me semble un peu trop complexe (ou rigide si tu préfères). En ce qui concerne ton problème particulier, je n'en connais pas véritablement la solution mais je pense (c'est déjà quelque chose) en connaître l'origine ; en réalité, je pense que le souci vient du fait que ta requête porte sur une table vide ( plus précisément sur une vue vide, celle générée par la Regime_allocations_part2_CMSA) ; la clause ifnull permet de sauter un champ null dans un enregistrement mais, en l'occurrence, il n'y a carrément pas d'enregistrement (puisqu'aucun enregistrement de la table demandeurs ne correspond aux critères fixés dans cette fameuse requête Regime_allocations_part2_CMSA. Pour éviter ça, je me suis dit que, peut-être, tu pourrais faire une requête (et éventuellement une vue) synthétisant, sur la période requise, le nombre d'allocataires de type part1 pour chaque code d'allocation ; ta requête Regime_allocation_partie1_CMSA deviendrait : SELECT COUNT( Demandeurs.part1alloc ) AS nombre1, Demandeurs.part1alloc FROM Mediations_toutes_Selection_periode, Demandeurs WHERE Mediations_toutes_Selection_periode.demandeurs = Demandeurs.no_demandeurs GROUP BY Demandeurs.part1alloc (en fait, je n'ai supprimé que la clause HAVING) Si on fait la même chose sur ta requête Regime_allocation_partie2_CMSA, elle devient : SELECT Demandeurs.part2alloc, COUNT( IFNULL( Demandeurs.part2alloc, 0 ) ) AS nombre2 FROM Mediations_toutes_Selection_periode, Demandeurs WHERE Mediations_toutes_Selection_periode.demandeurs = Demandeurs.no_demandeurs GROUP BY Demandeurs.part2alloc (ici aussi, donc, siplement suppression de la clause HAVING). Avec ces requêtes, on obtient un tableau regroupant, pour chaque code d'allocation, le nombre d'allocataires sur la période. La dernière requête est modifiée un peu plus en profondeur ; il s'agit de la requête Regime_allocations_CMSA_Total, qui devient : SELECT regimeCMSApart1.part1alloc, ifnull(nombre1,0) as nombre1, ifnull(nombre2,0) as nombre2, ifnull(regimeCMSApart1.nombre1,0) + ifnull(regimeCMSApart2.nombre2,0) AS Total FROM regimeCMSApart1 left join regimeCMSApart2 on regimeCMSApart1.part1alloc = regimeCMSApart2.part2alloc (attention, cette requête porte sur les vues ; il ne faut donc pas oublier de les modifier, sinon, elle sont toujours avec la clause HAVING) Tu obtiens avec ça un tableau comportant une colonne énonçant les différents types d'allocations rencontrés (ici, 0, 1 et 2), une colonne mentionnant le nombre d'allocataires partie 1 bénéficiant de ce type d'allocation (ou 0 s'il n'y en a pas mais en l'occurrence, ce n'est pas possible), un colonne mentionnant le nombre d'allocataires partie 2 bénéficiant de ce type d'allocation (ou 0, et ici c'est possible) et enfin une colonne totalisant les deux chiffres précédents. Je pense que, dans l'esprit, ça ressemble à ce que tu veux ; ensuite, si tu veux avoir une requête avec uniquement tel ou tel type d'allocation, tu peux parfaitement pointer sur cette dernière requête et en extraire nombre1 et noùmbre2 qui seront toujours renseignés (puisque le ifnull est utilisé pour créer cette requête). On pourra en re-discuter un peu plus tard si tu veux. A+
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
C'était aussi mon point de vue. D'après la documentation openoffice.org, le résultat de COUNT est un integer. Mais apparemment un integer qui ne connaît pas 0. Comme le fait que la requête 2 entraînait l'absence de résultat de la requête 3 j'ai pensé à null (qui se propage). Mais j'ai essayé toutes les commandes sensées traiter le null (pendant 2 jours :'( !) et pas moyen de trouver :'( Et donc j'ai fini par me dire que si pas 0, si pas null... rien ? demain, dès l'aube, à l'heure où blanchit la campagne... je teste les requêtes modifiées par Docgranville :D Le 21 avril 2010 22:45, ribotb rib...@gmail.com a écrit : Je n'ai pas encore examiné ta base mais à te lire et à priori j'aurais dit que si les requêtes ne renvoient aucun tuple, le résultat du COUNT devrait être 0. Le 21/04/2010 22:35, Marie-Pierre CORONEL a écrit : Salut, et pourtant la solution de Docgranville passe par Ifnull (que j'ai essayé sans succès, je comprendrais sûrement demain pourquoi -_-) Le 21 avril 2010 22:30, ribotbrib...@gmail.com a écrit : Bonsoir Marie-Pierre, Je ne me suis pas penché sur ce problème (intéressant) mais je peux te dire en tout cas que le résultat ne peut pas être NULL. NULL n'est pas une valeur mais c'est un *état *qui indique que la valeur d'un élément est inconnue ou indéterminée. Bernard Le 21/04/2010 19:11, Marie-Pierre CORONEL a écrit : re bonjour, non non, je ne tiens pas à traiter les 3 régimes différemment, j'avais essayé d'obtenir les calculs sur les 3 d'un coup mais je n'obtenais jamais un chiffre juste -_- La seule fois où j'ai enfin obtenu un chiffre juste c'est avec le système des 3 requêtes sauf quand j'ai testé avec 0 occurence. Là je suis rentrée chez moi, mais je regarderai tes requêtes demain. Je veux bien qu'on discute de la rigidité de ma base, parce que j'ai essayé de faire le plus pérenne possible et donc le contraire :'( mais bon... a+ Le 21 avril 2010 19:04, Docgranvilledocgranvi...@aol.com a écrit : Le 21/04/2010 18:04, Marie-Pierre CORONEL a écrit : hum j'ai voulu faire du ménage dans ci-joint... et j'ai supprimé le mauvais fichier... nouveau lien http://www.cijoint.fr/cjlink.php?file=cj201004/cijMs7dYvM.odb Re-bonjour Marie-Pierre, J'ai jeté un coup d'oeil rapide sur ta base ; peut-être aurais-je (à l'occasion) quelques réflexions à te faire partager sur sa conception qui me semble un peu trop complexe (ou rigide si tu préfères). En ce qui concerne ton problème particulier, je n'en connais pas véritablement la solution mais je pense (c'est déjà quelque chose) en connaître l'origine ; en réalité, je pense que le souci vient du fait que ta requête porte sur une table vide ( plus précisément sur une vue vide, celle générée par la Regime_allocations_part2_CMSA) ; la clause ifnull permet de sauter un champ null dans un enregistrement mais, en l'occurrence, il n'y a carrément pas d'enregistrement (puisqu'aucun enregistrement de la table demandeurs ne correspond aux critères fixés dans cette fameuse requête Regime_allocations_part2_CMSA. Pour éviter ça, je me suis dit que, peut-être, tu pourrais faire une requête (et éventuellement une vue) synthétisant, sur la période requise, le nombre d'allocataires de type part1 pour chaque code d'allocation ; ta requête Regime_allocation_partie1_CMSA deviendrait : SELECT COUNT( Demandeurs.part1alloc ) AS nombre1, Demandeurs.part1alloc FROM Mediations_toutes_Selection_periode, Demandeurs WHERE Mediations_toutes_Selection_periode.demandeurs = Demandeurs.no_demandeurs GROUP BY Demandeurs.part1alloc (en fait, je n'ai supprimé que la clause HAVING) Si on fait la même chose sur ta requête Regime_allocation_partie2_CMSA, elle devient : SELECT Demandeurs.part2alloc, COUNT( IFNULL( Demandeurs.part2alloc, 0 ) ) AS nombre2 FROM Mediations_toutes_Selection_periode, Demandeurs WHERE Mediations_toutes_Selection_periode.demandeurs = Demandeurs.no_demandeurs GROUP BY Demandeurs.part2alloc (ici aussi, donc, siplement suppression de la clause HAVING). Avec ces requêtes, on obtient un tableau regroupant, pour chaque code d'allocation, le nombre d'allocataires sur la période. La dernière requête est modifiée un peu plus en profondeur ; il s'agit de la requête Regime_allocations_CMSA_Total, qui devient : SELECT regimeCMSApart1.part1alloc, ifnull(nombre1,0) as nombre1, ifnull(nombre2,0) as nombre2, ifnull(regimeCMSApart1.nombre1,0) + ifnull(regimeCMSApart2.nombre2,0) AS Total FROM regimeCMSApart1 left join regimeCMSApart2 on regimeCMSApart1.part1alloc = regimeCMSApart2.part2alloc (attention, cette requête porte sur les vues ; il ne faut donc pas oublier de les modifier, sinon, elle sont toujours avec la clause HAVING) Tu obtiens avec ça un tableau comportant une colonne énonçant les différents types d'allocations rencontrés (ici, 0, 1 et 2), une colonne mentionnant le nombre d'allocataires partie 1 bénéficiant de ce type d'allocation (ou
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
Ç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 . Le 21/04/2010 23:12, Marie-Pierre CORONEL a écrit : C'était aussi mon point de vue. D'après la documentation openoffice.org, le résultat de COUNT est un integer. Mais apparemment un integer qui ne connaît pas 0. Comme le fait que la requête 2 entraînait l'absence de résultat de la requête 3 j'ai pensé à null (qui se propage). Mais j'ai essayé toutes les commandes sensées traiter le null (pendant 2 jours :'( !) et pas moyen de trouver :'( Et donc j'ai fini par me dire que si pas 0, si pas null... rien ? demain, dès l'aube, à l'heure où blanchit la campagne... je teste les requêtes modifiées par Docgranville :D Le 21 avril 2010 22:45, ribotbrib...@gmail.com a écrit : Je n'ai pas encore examiné ta base mais à te lire et à priori j'aurais dit que si les requêtes ne renvoient aucun tuple, le résultat du COUNT devrait être 0. Le 21/04/2010 22:35, Marie-Pierre CORONEL a écrit : Salut, et pourtant la solution de Docgranville passe par Ifnull (que j'ai essayé sans succès, je comprendrais sûrement demain pourquoi -_-) Le 21 avril 2010 22:30, ribotbrib...@gmail.coma écrit : Bonsoir Marie-Pierre, Je ne me suis pas penché sur ce problème (intéressant) mais je peux te dire en tout cas que le résultat ne peut pas être NULL. NULL n'est pas une valeur mais c'est un *état *qui indique que la valeur d'un élément est inconnue ou indéterminée. Bernard Le 21/04/2010 19:11, Marie-Pierre CORONEL a écrit : re bonjour, non non, je ne tiens pas à traiter les 3 régimes différemment, j'avais essayé d'obtenir les calculs sur les 3 d'un coup mais je n'obtenais jamais un chiffre juste -_- La seule fois où j'ai enfin obtenu un chiffre juste c'est avec le système des 3 requêtes sauf quand j'ai testé avec 0 occurence. Là je suis rentrée chez moi, mais je regarderai tes requêtes demain. Je veux bien qu'on discute de la rigidité de ma base, parce que j'ai essayé de faire le plus pérenne possible et donc le contraire :'( mais bon... a+ Le 21 avril 2010 19:04, Docgranvilledocgranvi...@aol.com a écrit : Le 21/04/2010 18:04, Marie-Pierre CORONEL a écrit : hum j'ai voulu faire du ménage dans ci-joint... et j'ai supprimé le mauvais fichier... nouveau lien http://www.cijoint.fr/cjlink.php?file=cj201004/cijMs7dYvM.odb Re-bonjour Marie-Pierre, J'ai jeté un coup d'oeil rapide sur ta base ; peut-être aurais-je (à l'occasion) quelques réflexions à te faire partager sur sa conception qui me semble un peu trop complexe (ou rigide si tu préfères). En ce qui concerne ton problème particulier, je n'en connais pas véritablement la solution mais je pense (c'est déjà quelque chose) en connaître l'origine ; en réalité, je pense que le souci vient du fait que ta requête porte sur une table vide ( plus précisément sur une vue vide, celle générée par la Regime_allocations_part2_CMSA) ; la clause ifnull permet de sauter un champ null dans un enregistrement mais, en l'occurrence, il n'y a carrément pas d'enregistrement (puisqu'aucun enregistrement de la table demandeurs ne correspond aux critères fixés dans cette fameuse requête Regime_allocations_part2_CMSA. Pour éviter ça, je me suis dit que, peut-être, tu pourrais faire une requête (et éventuellement une vue) synthétisant, sur la période requise, le nombre d'allocataires de type part1 pour chaque code d'allocation ; ta requête Regime_allocation_partie1_CMSA deviendrait : SELECT COUNT( Demandeurs.part1alloc ) AS nombre1, Demandeurs.part1alloc FROM Mediations_toutes_Selection_periode, Demandeurs WHERE Mediations_toutes_Selection_periode.demandeurs = Demandeurs.no_demandeurs GROUP BY Demandeurs.part1alloc (en fait, je n'ai supprimé que la clause HAVING) Si on fait la même chose sur ta requête Regime_allocation_partie2_CMSA, elle devient : SELECT Demandeurs.part2alloc, COUNT( IFNULL( Demandeurs.part2alloc, 0 ) ) AS nombre2 FROM Mediations_toutes_Selection_periode, Demandeurs WHERE Mediations_toutes_Selection_periode.demandeurs = Demandeurs.no_demandeurs GROUP BY Demandeurs.part2alloc (ici aussi, donc, siplement suppression de la clause HAVING). Avec ces requêtes, on obtient un tableau regroupant, pour chaque code d'allocation, le nombre d'allocataires sur la période. La dernière requête est modifiée un peu plus en profondeur ; il s'agit de la requête Regime_allocations_CMSA_Total, qui devient : SELECT regimeCMSApart1.part1alloc, ifnull(nombre1,0) as nombre1, ifnull(nombre2,0) as nombre2, ifnull(regimeCMSApart1.nombre1,0) + ifnull(regimeCMSApart2.nombre2,0) AS Total FROM regimeCMSApart1 left join regimeCMSApart2 on regimeCMSApart1.part1alloc = regimeCMSApart2.part2alloc (attention, cette requête
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
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
Re: [users-fr] résultat COUNT n'est pas 0 ni null ?
En fait, avant la création des vues, c'est à dire par exemple si tu transformes un des faux enregistrements des autres régimes pour qu'il n'y ait pas d'occurence sur l'un des champs, tu verras que le résultat est le même qu'avec les vues : aucun enregistrement dans requête 3 même sans vue quand l'une des requêtes 1 ou 2 ne ramène rien. J'ai cru faire preuve d'astuce en mettant un des enregistrements CAF en CMSA avant la création de la vue, donc les vues ramenaient toutes les deux quelque chose, mais après réinscription en CAF au lieu de CMSA... tu as vu le résultat par toi même... Le 21 avril 2010 23:51, Docgranville docgranvi...@aol.com 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
