Discussion :

[marcel marie]

Bonjour,
L'intitulé n'est peut-être pas précis ! En plus je parle MySql ...
Dans une table, j'ai une clé (unique) sur trois champs A,B,C
Pour mon cas le champ C est char(3). B (char 5), A une date (yyyy-mm-jj)
Je voudrais pouvoir ne pas accepter de prendre en compte un enregistrement dès lors que l'un des champs n'est pas renseigné, s'il est vierge par conséquent.
Est-ce que à partir de la structure de la table et de la définition du champ je peux imposer cette contrainte sans avoir à tester le contenu du champ avant d'écrire l'enregistrement.
C'est ce que je faisais jusqu'à présent mais visiblement j'ai dû rater qqch car j'ai quelques enregistrements avec C vierge et je ne trouve pas où.
Je vous remercie.

Marcel Marie

[CinePhil]

La clause NOT NULL a t-elle été placée sur les trois colonnes (et pas champ !) ?

On peut avoir la structure de la table ?

[marcel marie]

Bonjour,
En pièces jointes ce qui est demandé. J'espère que ça va partir, sinon je réessaie.
Champ ou colonne, selon les habitudes !! Mysql titre la chose : "champ".
Je ne trouve pas la zone où mettre l'éventuel NOT NULL !!
Je vous remercie.
Marcel Marie

[CinePhil]

Champ ou colonne, selon les habitudes !! Mysql titre la chose : "champ".

En l'occurrence, dans ce que tu montres, ce n'est pas forcément MySQL qui appelle ça "champ" mais phpMyAdmin.
Pour ajouter une colonne en SQL, l'instruction est ADD COLUMN, pas ADD FIELD !

Je ne trouve pas la zone où mettre l'éventuel NOT NULL !!

Regarde bien les images que tu as postées !
Sur la première, il y a une colonne "Null" qui est entièrement à "Non" ; ça veut dire que toutes les colonnes de la tables sont NOT NULL.
Sur la seconde, c'est carrément écrit "not null" dans la liste déroulante intitulée "Null" !

Revenons à ta demande d'origine :

Je voudrais pouvoir ne pas accepter de prendre en compte un enregistrement dès lors que l'un des champs n'est pas renseigné, s'il est vierge par conséquent.

Comme les colonnes sont NOT NULL, elles ne peuvent pas être vides. Après ça dépend comment tu insères les données. Si ton programme est susceptible d'insérer la chaîne vide '', la valeur sera acceptée par chaque colonne, mais pour le triplet une seule fois.
C'est au programme utilisateur de contrôler la qualité des données saisies :
- les champs (et cette fois il s'agit bien de champs !) du formulaire sont-ils tous non vides ?
- le champ date est-il bien une date ?

D'ailleurs, vu la structure de la table, je suppose que Io_commune et Io_orchestre sont deux colonnes faisant référence à l'identifiant d'une commune et d'un orchestre, autrement dit, même si tu ne les utilises pas formellement à cause du moteur MyISAM, des clés étrangères non ?
Donc l'interface utilisateur devrait proposer la liste existante des communes et des orchestres, ce qui implique qu'un choix dans ces listes est forcément valide, à condition que l'utilisateur ait vraiment choisi.

Bref, tu as deux solutions :
1) Comme dit plus haut, contrôler la saisie par le programme utilisateur avant envoi de la requête au serveur.
2) Développez un trigger en SQL pour vérifier que les données sont valides et retourner un code d'erreur... qu'il faut ensuite gérer dans le programme utilisateur.

[Jihnn]

En l'occurrence, dans ce que tu montres, ce n'est pas forcément MySQL qui appelle ça "champ" mais phpMyAdmin.

Semi-HS pour dire qu'un membre de Developpez (Oishii je crois sur ce forum) a envoyé un mail aux auteurs de phpmyadmin et ils ont dit qu'ils corrigeraient l'orthographe de certains mots, notamment field / champ => column / colonne et "Enregistrement" => ligne.

[marcel marie]

Bonjour,
L'essentiel est de se comprendre aussitôt et "sur le champ" !!!. Merci.
Réponse à CinePhil :
Pas forcément doué mais tout de même assez habitué aux manipulations des bases de données, je crois avoir tout fait ce que vous me dîtes.
Outre la date dont la validité est vérifiée, les colonnes sont récupérées dans des tables et proposées pour les seules valeurs existantes et pour lesquelles le champ de saisie ne peut être vierge, contrôlé par script.
Donc une colonne vierge ne devrait pas pouvoir passer !!!
Or cela s'est produit 4 fois dans un laps de temps de 10 mn environ, jamais avant et jamais après semble-t-il !?
Donc il y a qqch de plus vicieux que je m'efforce de découvrir.
Je me demande en particulier si la personne qui a fait la mise à jour n'a pas ouvert en même temps le même programmme chez lui sur deux connexions Wifi et/ou ethernet et si une variable de session mise à blanc à l'initialisation ne s'est pas "transportée" sur la procédure de contrôle remplaçant la valeur de la colonne "insidieusement".
Je ne vais pas m'éterniser sur ce problème mais chaque matin, pendant 8-15 jours j'irai vérifier dans la base la présence éventuelle d'une colonne vierge. Une bonne vingtaine de personnes sont habilitées à faire des mises à jour avec des mots de passe différents et il est toujours difficile à postériori de savoir ce qu'elles ont fait précisément. Mais s'il y a à nouveau ce bug, je saurais qui .

Je vous remercie de votre patience sur ce problème, que je qualifierai de "curieux" en attente de sa compréhension.

Marcel Marie