'Erik' un mot réservé ?

MySQL

Sujet résolu

26 novembre 2010 à 4:42:10

Salut,

Je prépare un petit site pour 4 membres d'une famille avec messages et module de recherche. L'un d'eux s'appelle Erik et c'est ça le problème, parce que la recherche ignore complètement ce mot ! (MATCH... AGAINST())

Qu'on écrive erik ERIK Erik érik ÉRIK ou Érik (bien que cette recherche ignore la casse, mais on ne sait jamais), rien à faire, le module ne retourne rien. Tout le reste, à part des mots courts, fonctionne. Et je n'ai pas de système d'exceptions en place donc tout porte à croire que MySQL ignore simplement le mot Erik. Sinon je trouverais d'autres anomalies.

Mais pourquoi ferait-il cela ? Et pourquoi ne figurerait-t-il pas dans cette liste dans ce cas ?

ADD ALL ALTER
ANALYZE AND AS
ASC ASENSITIVE BEFORE
BETWEEN BIGINT BINARY
BLOB BOTH BY
CALL CASCADE CASE
CHANGE CHAR CHARACTER
CHECK COLLATE COLUMN
CONDITION CONSTRAINT CONTINUE
CONVERT CREATE CROSS
CURRENT_DATE CURRENT_TIME CURRENT_TIMESTAMP
CURRENT_USER CURSOR DATABASE
DATABASES DAY_HOUR DAY_MICROSECOND
DAY_MINUTE DAY_SECOND DEC
DECIMAL DECLARE DEFAULT
DELAYED DELETE DESC
DESCRIBE DETERMINISTIC DISTINCT
DISTINCTROW DIV DOUBLE
DROP DUAL EACH
ELSE ELSEIF ENCLOSED
ESCAPED EXISTS EXIT
EXPLAIN FALSE FETCH
FLOAT FLOAT4 FLOAT8
FOR FORCE FOREIGN
FROM FULLTEXT GRANT
GROUP HAVING HIGH_PRIORITY
HOUR_MICROSECOND HOUR_MINUTE HOUR_SECOND
IF IGNORE IN
INDEX INFILE INNER
INOUT INSENSITIVE INSERT
INT INT1 INT2
INT3 INT4 INT8
INTEGER INTERVAL INTO
IS ITERATE JOIN
KEY KEYS KILL
LEADING LEAVE LEFT
LIKE LIMIT LINES
LOAD LOCALTIME LOCALTIMESTAMP
LOCK LONG LONGBLOB
LONGTEXT LOOP LOW_PRIORITY
MATCH MEDIUMBLOB MEDIUMINT
MEDIUMTEXT MIDDLEINT MINUTE_MICROSECOND
MINUTE_SECOND MOD MODIFIES
NATURAL NOT NO_WRITE_TO_BINLOG
NULL NUMERIC ON
OPTIMIZE OPTION OPTIONALLY
OR ORDER OUT
OUTER OUTFILE PRECISION
PRIMARY PROCEDURE PURGE
READ READS REAL
REFERENCES REGEXP RELEASE
RENAME REPEAT REPLACE
REQUIRE RESTRICT RETURN
REVOKE RIGHT RLIKE
SCHEMA SCHEMAS SECOND_MICROSECOND
SELECT SENSITIVE SEPARATOR
SET SHOW SMALLINT
SONAME SPATIAL SPECIFIC
SQL SQLEXCEPTION SQLSTATE
SQLWARNING SQL_BIG_RESULT SQL_CALC_FOUND_ROWS
SQL_SMALL_RESULT SSL STARTING
STRAIGHT_JOIN TABLE TERMINATED
THEN TINYBLOB TINYINT
TINYTEXT TO TRAILING
TRIGGER TRUE UNDO
UNION UNIQUE UNLOCK
UNSIGNED UPDATE USAGE
USE USING UTC_DATE
UTC_TIME UTC_TIMESTAMP VALUES
VARBINARY VARCHAR VARCHARACTER
VARYING WHEN WHERE
WHILE WITH WRITE
XOR YEAR_MONTH ZEROFILL

The following are new reserved words in MySQL 5.0:

ASENSITIVE CALL CONDITION
CONNECTION CONTINUE CURSOR
DECLARE DETERMINISTIC EACH
ELSEIF EXIT FETCH
GOTO INOUT INSENSITIVE
ITERATE LABEL LEAVE
LOOP MODIFIES OUT
READS RELEASE REPEAT
RETURN SCHEMA SCHEMAS
SENSITIVE SPECIFIC SQL
SQLEXCEPTION SQLSTATE SQLWARNING
TRIGGER UNDO UPGRADE
WHILE

C'est un truc bizarre et j'aimerais bien comprendre, alors s'il vous plait n'hésitez pas à y aller de vos petites allégations pour essayer de faire avancer le Schmilblick.

Merci.

Même en rentrant ces requêtes dans PHPMyAdmin ça ne me retourne rien...

SELECT * FROM table WHERE MATCH pseudo, titre, message AGAINST ('erik') ORDER BY id DESC

CSS3/HTML5 -> TP : diaporama original en CSS

Fayden

26 novembre 2010 à 5:29:00

Si tu fais SELECT * FROM table , qu'est-ce que ça retourne ?

Lord Casque Noir

26 novembre 2010 à 9:45:51

Attention, si tu as une table de test avec juste 3 lignes dedans, mysql ignore les mots qui sont présents dans plus de X% des lignes (je crois que c'est 50% je sais plus), ce qui est logique, ça élimine les mots comme "et", "avec", etc.

Fayden

26 novembre 2010 à 16:07:48

Citation : Lord Casque Noir

Attention, si tu as une table de test avec juste 3 lignes dedans, mysql ignore les mots qui sont présents dans plus de X% des lignes (je crois que c'est 50% je sais plus), ce qui est logique, ça élimine les mots comme "et", "avec", etc.

Ouais, c'est bien ce à quoi je pensais.

Ceriko

26 novembre 2010 à 18:21:07

C'est exactement ce que je me disais, alors j'avais éliminé beaucoup de messages et ça n'avait rien changé.

Je viens d'en éliminer 3 de plus et ça y est, Erik est pris en compte dans la recherche ! Mais c'est quand même embêtant comme truc. si 2 personnes partagent un système de données alors il y en aura forcément une qui aura plus de messages que l'autre et la recherche sur pseudo ne fonctionnera que pour l'un des deux... après il suffit de faire autrement (avec un if par exemple) mais ça devient compliqué à gérer.

Merci pour vos participations, je passe le sujet en résolu.

Ceriko.

CSS3/HTML5 -> TP : diaporama original en CSS