Error: Code 1054. Unknown column "U2.id_naslov" in "field list"
est lancé sur cette simple requête dans MySQL Workbench :
UPDATE krneki_1 AS U1, krneki_2 AS U2 SET U1.id_naslov = U2.id_naslov WHERE (U2.id_zaposlen = U1.id_naslovi_zaposleni)
Jai recherché et lu dautres articles sur le net mais rien ny fait …
Je suppose que cest « une solution triviale mais je ne peux pas le voir.
Ce genre derreur nest jamais survenu sur TSQL (serveur sql).
La table krneki_2 a été créée par Mysql workbench via limportation de données (créer un nouveau table) plus tard, lorsque cette erreur sest produite, jai également modifié les champs numériques en smallint juste pour voir si cela aide … mais … rien.
Résultat de SHOW CREATE TABLE krneki_2
:
Table: krneki_2 Create Table: CREATE TABLE `krneki_2` ( `id` smallint(6) NOT NULL AUTO_INCREMENT, `id_naslov` smallint(6) NOT NULL, `id_zaposlen` smallint(6) NOT NULL, PRIMARY KEY (id) ) ENGINE=InnoDB AUTO_INCREMENT=204 DEFAULT CHARSET=utf8 1 row in set (0.00 sec)
Résultat de SHOW CREATE TABLE krneki_1
:
Table: krneki_1 Create Table: CREATE TABLE `krneki_1` ( `id_naslovi_zaposleni` smallint(6) NOT NULL AUTO_INCREMENT, `id_naslov` smallint(6) DEFAULT NULL, `id_zaposleni` smallint(6) DEFAULT NULL, `id_aktiven` tinyint(4) DEFAULT "0", `cas_vnosa` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id_naslovi_zaposleni`) ) ENGINE=InnoDB AUTO_INCREMENT=256 DEFAULT CHARSET=utf8 1 row in set (0.00 sec)
Résultats de information_schema
, spécifiquement de cette requête suggérée dans les commentaires:
select table_catalog, table_schema, table_name, column_name, ordinal_position from information_schema.columns where table_name like "%krneki_1%" and column_name like "%naslov%" ;
Résultats pour krneki_1
et naslov
:
Résultats pour krneki_2
et naslov
:
+---------------+--------------+-------------+--------------+------------------+ | table_catalog | table_schema | table_name | column_name | ordinal_position | +---------------+--------------+-------------+--------------+------------------+ | def | hq_db | krneki_2 | id_naslov | 2 | +---------------+--------------+-------------+--------------+------------------+ 1 row in set (0.00 sec)
Résultats pour krneki_2
et zaposlen
:
+---------------+--------------+-------------+--------------+------------------+ | table_catalog | table_schema | table_name | column_name | ordinal_position | +---------------+--------------+-------------+--------------+------------------+ | def | hq_db | krneki_2 | id_zaposlen | 3 | +---------------+--------------+-------------+--------------+------------------+ 1 row in set (0.00 sec)
Poursuite des recherches, comme suggéré:
select table_catalog, table_schema, table_name, column_name, ordinal_position, char_length(column_name) as cl, length(column_name) as l from information_schema.columns where table_name = "krneki_2" ;
Résultats pour krneki_2
:
+-------------+------------+----------+-----------+----------------+---+---+-------------+ |table_catalog|table_schema|table_name|column_name|ordinal_position| cl| l | column_type | +-------------+------------+----------+-----------+----------------+---+---+-------------+ | def | hq_db | krneki_2 |id | 1 | 2| 2| smallint(6) | | def | hq_db | krneki_2 |id_naslov | 2 | 10| 12| smallint(6) | | def | hq_db | krneki_2 |id_zaposlen| 3 | 11| 11| smallint(6) | +-------------+------------+----------+-----------+----------------+---+---+-------------+ 3 rows in set (0.00 sec)
Résultats pour krneki_1
:
+-------------+------------+----------+--------------------+----------------+--+--+-----------+ |table_catalog|table_schema|table_name| column_name |ordinal_position|cl| l|column_type| +-------------+------------+----------+--------------------+----------------+--+--+-----------+ | def | hq_db | krneki_1 |id_naslovi_zaposleni| 1 |20|20|smallint(6)| | def | hq_db | krneki_1 |id_naslov | 2 | 9| 9|smallint(6)| | def | hq_db | krneki_1 |id_zaposleni | 3 |12|12|smallint(6)| | def | hq_db | krneki_1 |id_aktiven | 4 |10|10|tinyint(4) | | def | hq_db | krneki_1 |cas_vnosa | 5 | 9| 9|datetime | +-------------+------------+----------+--------------------+----------------+--+--+-----------+ 5 rows in set (0.00 sec)
krneki_2 avec HEX :
+-------------+------------+----------+-----------+----------------+--+--+-------------------------+ |table_catalog|table_schema|table_name|column_name|ordinal_position|cl|l | hex | +-------------+------------+----------+-----------+----------------+--+--+-------------------------+ | def | hq_db | krneki_2 |id | 1 | 2| 2|6964 | | def | hq_db | krneki_2 |id_naslov | 2 |10|12|EFBBBF69645F6E61736C6F76 | | def | hq_db | krneki_2 |id_zaposlen| 3 |11|11|69645F7A61706F736C656E | +-------------+------------+----------+-----------+----------------+--+--+-------------------------+ 3 rows in set (0.00 sec)
krneki_1 avec HEX:
+-------------+------------+----------+--------------------+----------------+--+--+----------------------------------------+ |table_catalog|table_schema|table_name|column_name |ordinal_position|cl| l|hex | +-------------+------------+----------+--------------------+----------------+--+--+----------------------------------------+ | def | hq_db | krneki_1 |id_naslovi_zaposleni| 1 |20|20|69645F6E61736C6F76695F7A61706F736C656E69| | def | hq_db | krneki_1 |id_naslov | 2 | 9| 9|69645F6E61736C6F76 | | def | hq_db | krneki_1 |id_zaposleni | 3 |12|12|69645F7A61706F736C656E69 | | def | hq_db | krneki_1 |id_aktiven | 4 |10|10|69645F616B746976656E | | def | hq_db | krneki_1 |cas_vnosa | 5 | 9| 9|6361735F766E6F7361 | +-------------+------------+----------+--------------------+----------------+--+--+----------------------------------------+ 5 rows in set (0.00 sec)
Réponse
Le message derreur est assez clair. La table krneki_2
na pas de colonne nommée id_naslov
. À moins quil y ait une corruption dans les tables système ou un bogue, cela ne fait aucun doute.
Nous devons donc éliminer plusieurs possibilités pour lesquelles cela apparaît:
-
Il existe des incohérences entre les instructions
CREATE TABLE
et lesUPDATE
:CREATE TABLE ` krneki_1` ... CREATE TABLE ` krneki_2` ... UPDATE krneki_1 AS U1, krneki_2 AS U2 ...
La non-concordance est un espace au début des noms.
Cela aurait dû donner une erreur de « La table » krneki_1 « nexiste pas » donc je suppose que vous avez deux versions de la table krneki_1
, et la version sans espace na pas la colonne id_naslov
.
Nous avons éliminé cette possibilité, cétait une erreur de copier-coller depuis lOP.
-
Le nom de la colonne dans le
CREATE TABLE
et leUPDATE
ne sont pas identiques. Ils peuvent se ressembler, mais il peut y avoir des caractères non imprimables ou ils peuvent avoir des caractères Unicode qui se ressemblent mais sont des points de code différents. Pour le savoir, nous pouvons utiliser cette requête:select table_catalog, table_schema, table_name, column_name, ordinal_position, char_length(column_name) as cl, length(column_name) as l, hex(column_name) as hex from information_schema.columns where table_name = "krneki_2" ;
qui révèle la différence (colonnes non nécessaires supprimées du résultat) :
+------------+-------------+------------------+----+----+ | table_name | column_name | ordinal_position | cl | l | +------------+-------------+------------------+----+----+ | krneki_2 | id | 1 | 2 | 2 | | krneki_2 | id_naslov | 2 | 10 | 12 | -- !!! -- | krneki_2 | id_zaposlen | 3 | 11 | 11 | +------------+-------------+------------------+----+----+
La note 12 est supérieure à 10 et il y a le problème! Cela signifie que le nom de la colonne a 10 caractères et utilise 12 octets. Ces nombres devraient tous les deux être 9 (si nous comptons id_naslov
correctement et si tous les 9 caractères étaient ASCII), il se passe donc quelque chose de louche.
Vous pouvez ajoutez hex(column_name)
dans la liste de sélection de cette dernière requête et nous saurons quel est exactement le nom de la colonne. Ensuite, vous pouvez le modifier pour navoir que des caractères ascii imprimables.
Pour réparer, vous avez besoin de quelque chose comme ceci:
set @column := X"EFBBBF69645F6E61736C6F76" ; set @qry:= concat("alter table krneki_2 change column ", @column, " id_naslov smallint") ; prepare stmt from @qry ; execute stmt ;
Réponse
Le problème peut être que vous aviez oublié dexécuter une instruction use <database>;
, et par conséquent, vous navez pas exécuté linsertion dans la bonne base de données.
En dautres termes, vous essaie peut-être de sinsérer dans une table qui existe dans une autre base de données, mais avec une structure différente.
Réponse
Le problème peut être avec des alias dans plusieurs tables UPDATEs
et DELETEs
. Jai trouvé des cas où AS k2
ne fonctionne pas comme on pourrait sy attendre. Supprimez les alias et utilisez simplement les noms de table.