Discussion :

[enzostar]

Bonjour,
j'aimerais insérer comme valeur pour un champ (et uniquement ça) un espace.
Mais jen'y arrive pas même depuis l'interface phpMyadmin.
La chaine a l'air d'être considérée comme vide et elle est insérée ainsi en base.

Merci pour votre aide

[CinePhil]

Es-tu sûr de ce que tu dis ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
CREATE  TABLE  `test`.`toto` ( `id` INT NOT  NULL  AUTO_INCREMENT ,
 `A` VARCHAR( 10  )  NOT  NULL ,
 PRIMARY  KEY (  `id`  ) 
) ENGINE  =  MYISAM ;

La table `test`.`test` a été créée.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
INSERT  INTO  `test`.`toto` ( `id` ,
 `A` 
)
VALUES ( NULL ,  ' '
), ( NULL ,  'a'
);

2 enregistrement(s) inséré(s).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT  * 
FROM  `toto` 
WHERE a =  ' '

Il m'affiche bien la ligne d'id 1.

[enzostar]

mes tables ont été crées comme cela

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

engine=InnoDB

[enzostar]

Es-tu sûr de ce que tu dis ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
CREATE  TABLE  `test`.`toto` ( `id` INT NOT  NULL  AUTO_INCREMENT ,
 `A` VARCHAR( 10  )  NOT  NULL ,
 PRIMARY  KEY (  `id`  ) 
) ENGINE  =  MYISAM ;

La table `test`.`test` a été créée.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
INSERT  INTO  `test`.`toto` ( `id` ,
 `A` 
)
VALUES ( NULL ,  ' '
), ( NULL ,  'a'
);

2 enregistrement(s) inséré(s).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT  * 
FROM  `toto` 
WHERE a =  ' '

Il m'affiche bien la ligne d'id 1.

remplaces ' ' par '' s'il te plait et dis moi ce que tu obtiens

[CinePhil]

Ceci : '' est une chaîne vide (deux apostrophes sans espace).
Cela : ' ' est une chaîne composée d'un espace (deux apostrophes avec un espace).

Tu as dit que tu voulais insérer un espace, pas une chaîne vide.

[enzostar]

peux tu refaire ton select avec les deux apostrophes sans espace ?
Je suis quasiment sûr qu'il te retourme quand même l'enregistrement (en tous cas moi il le fait).

[CinePhil]

Effectivement !
C'est donc un bug de plus chez MySQL ! SQLPro va se régaler !

Je ne sais pas si c'est pareil avec d'autres SGBD mais ça m'étonnerait quand même !

[jeca]

Bonjour,

Extrait du manuel Mysql :

La longueur d'une colonne CHAR est fixée à la longueur que vous avez défini lors de la création de la table. La longueur peut être n'importe quelle valeur entre 1 et 255. (Dans la version 3.23 de MySQL, la longueur est comprise entre 0 et 255.) Quand une valeur CHAR est enregistrée, elle est complété à droite avec des espaces jusqu'à atteindre la valeur fixée. Quand une valeur de CHAR est lue, les espaces en trop sont retirés.

Les valeurs contenues dans les colonnes de type VARCHAR sont de tailles variables. Vous pouvez déclarer une colonne VARCHAR pour que sa taille soit comprise entre 1 et 255, exactement comme pour les colonnes CHAR. Par contre, contrairement à CHAR, les valeurs de VARCHAR sont stockées en utilisant autant de caractères que nécessaire, plus un octet pour mémoriser la longueur. Les valeurs ne sont pas complétées. Au contraire, les espaces finaux sont supprimés avant stockage (ce qui ne fait pas partie des spécifications ANSI SQL).

[CinePhil]

Le problème est bien là :

Au contraire, les espaces finaux sont supprimés avant stockage (ce qui ne fait pas partie des spécifications ANSI SQL).

Une fois de plus, MySQL est hors norme !

On peut se demander pourquoi vouloir insérer juste un espace dans une colonne mais selon la norme on devrait avoir le droit de le faire et MySQL en fait ne le permet pas.

Enzostar, pourquoi veux-tu insérer seulement un espace ?

[ok.Idriss]

Effectivement j'ai le même bug :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
mysql> insert into dept values (50, ' ', ' ');                                                                    
Query OK, 1 row affected (0,00 sec)  
 
mysql> select * from dept;
+--------+-------------+--------+
| n_dept | nom         | lieu   |
+--------+-------------+--------+
|     10 | recherche   | Rennes | 
|     20 | vente       | Metz   | 
|     30 | direction   | Paris  | 
|     40 | fabrication | Toulon | 
|     50 |             |        | 
+--------+-------------+--------+ 
5 rows in set (0,00 sec)          
 
mysql> select * from dept where nom = '';
+--------+------+------+
| n_dept | nom  | lieu |
+--------+------+------+
|     50 |      |      |
+--------+------+------+
1 row in set (0,00 sec)
 
mysql>

[enzostar]

j'y suis parvenu en modifiant le type de ma colone en varbinary ce qui me donne le code hexadécimal de mon caractère. Et là, plus de soucis !

[Artemus24]

Salut à tous.

Je déterre ce vieux sujet concernant un soit disant bug. Il y a des points qui n'ont pas été soulevés correctement en ce qui concerne ce bug.
Après avoir fait quelques tests, il existe des différences de comportements.
Je tiens à préciser que les tests ont été faits pour déterminer la meilleure solution, pour distinguer, le NULL, le vide, et de la chaine à blanc.

J'ai testé à l'insertion, les valeurs suivantes :
--> chaine vide.
--> chaine avec un seul caractère à blanc.
--> NULL
-> DEFAULT.

Et voici le résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
+------------+----------+--------------+-------+----------+------+---------+---------+
|   FORMAT   |          |    DEFAULT   | = ' ' | LIKE ' ' | = '' | LIKE '' | IS NULL |
+------------+----------+--------------+-------+----------+------+---------+---------+
| VARCHAR(3) | NOT NULL | DEFAULT ''   |  NON  |    OUI   |  NON |   OUI   |   ---   |
| VARCHAR(3) |     NULL | DEFAULT NULL |  NON  |    OUI   |  NON |   OUI   |   OUI   |
+------------+----------+--------------+-------+----------+------+---------+---------+
|    CHAR(3) | NOT NULL | DEFAULT ''   |  NON  |    ---   |  NON |   NON   |   ---   |
|    CHAR(3) |     NULL | DEFAULT NULL |  NON  |    ---   |  NON |   NON   |   OUI   |
+------------+----------+--------------+-------+----------+------+---------+---------+

Légende :
--> 'oui' : résultat correcte.
--> 'non' : résultat incorrecte.
--> '---' : aucun résultats.

Constatation.

--> Utiliser la clause 'LIKE' pour tester une chaine de caractères, plutôt que '='.
Le '=' ne sait pas faire la distinction entre une chaine vide et une chaine à blanc.

--> privilégier le 'VARCHAR' plutôt que le 'CHAR'.
Le 'CHAR' ne sait pas reconnaitre une chaine à blanc. Aucun résultat n'est obtenu. (pour moi, le bug se trouve sur le 'CHAR').

--> mettre 'NULL' pour une chaine non renseignée.

--> si 'NOT NULL' dans la déclarative, à l'insertion, transforme le 'NULL' en chaine vide.

--> utiliser 'DEFAULT' si l'on ne sait pas quoi mettre.

Donc la bonne déclarative d'une chaine de caractères est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

`chaine` VARCHAR(255) NULL DEFAULT NULL

Et l'on test la chaine avec un seul blanc, en faisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

chaine LIKE ' '

Et l'on test la chaine vide, en faisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

chaine LIKE ''

@+

[aieeeuuuuu]

Bonjour,

Ce n'est en effet pas un bogue, et ce pauvre MySQL, pour une fois qu'il respecte la norme SQL en a pris pour son grade
Sur ce point, il semble d'ailleurs être le seul, avec SQL Server, à la respecter.

Celle-ci stipule que lors de comparaison de deux chaines de caractère de taille différente, la plus courte doit être préalablement complétée à droite avec le caractère de remplissage prévu par la collation, ou à défaut, par des espaces, afin que les deux chaines aient la même longueur.

En clair, les prédicats suivants sont tous vrais selon la norme SQL

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
'' = ''
'' = ' '
'toto' = 'toto              '

Avec le jeu d'essai suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
create table test (x int
                   , a VARCHAR(20)
                   , b VARCHAR(20)
             );
 
insert into test values (-2, ' ', NULL);
insert into test values (-1, '', NULL);
 
insert into test values (1,' ', ' ');
insert into test values (2,'', '');
insert into test values (3,'', ' ');
insert into test values (4,'toto', 'toto       ');
insert into test values (5,'', '       ');

J'ai lancé cette requete sur SQLFiddle pour tous les SGBD qu'il propose

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
select *
from test
where b = a

Cette requête devrait donc remonter les 5 lignes avec x positifs.

Les résultats sont étonnants :
MySQL et SQL Server sortent bien les lignes 1 à 5 .

PGSQL et SQLite sortent les lignes 1 et 2

Oracle ne sort que la ligne 1 (pas la 2 )

[Artemus24]

Salut aieeeuuuuu.

Tu as oublié IBM DB2 (Z/OS) sur gros système, qui est beaucoup plus ancien, que tous ces SGBDR que l'on trouve sur les micros et les mini.

D'après mes tests, ce qui me surprend, c'est que je ne suis pas capable de tester le caractère blanc sur un simple CHAR alors que ça fonctionne avec le VARCHAR.
Le caractère blanc est bien un caractère spécial, ayant sûrement la signification de chaîne vide quand il se présente seul.

Mais quel est l'intérêt d'avoir une chaîne avec des blancs ? Quel est sa signification fonctionnelle au sein d'une application ?
Je considère que fonctionnellement parlant, une chaîne vide, a la même signification qu'une chaîne renseignée avec des blancs, et doit être initialisé à NULL.
De ce fait, NULL désigne alors une colonne non renseignée, ou bien en attente d'une futur initialisation.

Merci de nous communiquer ces différences de comportement.
Je pense que tous les développeurs devraient connaitre ces particularités afin de ne pas les reproduire et de rester dans du standard compréhensible par tout le monde.

Je viens de faire le test, et voici ce que j'obtiens :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
+------+------+-------------+
| x    | a    | b           |
+------+------+-------------+
|    1 |      |             |
|    2 |      |             |
|    3 |      |             |
|    4 | toto | toto        |
|    5 |      |             |
+------+------+-------------+

Merci aieeeuuuuu !
@+

[aieeeuuuuu]

Tu as oublié IBM DB2 (Z/OS)

Non, je ne l'ai pas oublié, mais SQLFiddle ne le propose pas... (et je n'avais pas mon mainframe gonflable sur moi )

Je viens de faire le test, et voici ce que j'obtiens :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
+------+------+-------------+
| x    | a    | b           |
+------+------+-------------+
|    1 |      |             |
|    2 |      |             |
|    3 |      |             |
|    4 | toto | toto        |
|    5 |      |             |
+------+------+-------------+

Merci pour le test et à DB2 aussi alors !

[skuatamad]

Oracle ne sort que la ligne 1 (pas la 2 )

Pour oracle '' c'est null :
http://www.developpez.net/forums/d13...d/#post7533899

[Artemus24]

Salut aieeeuuuuu.

Je connais IBM DB2 car j'ai été, en mon temps, administrateur DB2, mais comme je suis à la retraite, je ne peux plus faire du mainframe.
Aujourd'hui, je me consacre à WampServer et tout ce qui tourne autour, et par conséquent à MySql.

Existe-t-il beaucoup de bugs sous MySql ?
Est-ce de véritables bugs ou une méconnaissance de la syntaxe exacte, voire même d'un problème mal posé ?

@+

[SQLpro]

Bon alors, la norme : ISO/IEC en date du 2007-12-17 - Part 2 : Foundation (SQL/Foundation), page 19
"
The comparison of two character string expressions depends on the collation used for the comparison (see
Subclause 9.13, “Collation determination”). When values of unequal length are compared, if the collation for
the comparison has the NO PAD characteristic and the shorter value is equal to some prefix of the longer value,
then the shorter value is considered less than the longer value. If the collation for the comparison has the PAD
SPACE characteristic, for the purposes of the comparison, the shorter value is effectively extended to the length
of the longer by concatenation of <space>s on the right.
"

Effectivement je m'amuse beaucoup avec mes étudiant et mes stagiaires avec des exercices sur des colonnes tantôt CHAR tantôt VARCHAR et des opérateurs comme LIKE qui prennent en compte ou pas les blancs suivante le type de données !

A +

[SQLpro]

Pour oracle '' c'est null :
http://www.developpez.net/forums/d13...d/#post7533899

Cela est du au fait que les aficionados d'Oracle conservent ne général un paramétrage imbécile pour des raisons de rétro compatibilité. Sans ce paramétrage il serait intéressant de faire de nouveaux tests.

A +