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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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,
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).
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
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
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
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
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 ;
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
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
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
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é
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é
Ç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
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
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
39 matches
Mail list logo
