Error: Code 1054. Unknown column "U2.id_naslov" in "field list" blir kastet på dette enkle spørsmålet i 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)

Jeg har søkt og lest andre innlegg på nettet, men ingenting hjelper …

Jeg antar at det er en triviell løsning men jeg kan bare ikke se det.

Denne typen feil kom aldri opp på TSQL (SQL Server).

Tabell krneki_2 ble opprettet av Mysql arbeidsbenk via dataimport (opprett ny senere da denne feilen oppstod, endret jeg også tallfeltene til smallint bare for å se om det hjelper … men … ingenting.

Resultat av 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)

Resultat av 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)

Resultater fra information_schema, spesielt fra dette spørsmålet foreslått i kommentarer: 

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%" ;

Resultater for krneki_1 og naslov:

Resultater for krneki_2 og 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)

Resultater for krneki_2 og 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)

Videre graving, som foreslått: 

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" ;

Resultater for 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)

Resultater for 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 med 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 med 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)

Svar

Feilmeldingen er ganske tydelig. Tabellen krneki_2 har ikke en kolonne som heter id_naslov. Med mindre det er noen korrupsjon i systemtabeller eller en feil, er det ingen spørsmål om det.

Så vi må eliminere flere muligheter for hvorfor dette vises:

  1. Det er uoverensstemmelser mellom CREATE TABLE utsagnene og UPDATE: 

    CREATE TABLE ` krneki_1` ... CREATE TABLE ` krneki_2` ... UPDATE krneki_1 AS U1, krneki_2 AS U2 ...

Misforholdet er et mellomrom i begynnelsen av navnene.

Dette burde ha gitt en feil på «Tabell» krneki_1 «eksisterer ikke» så min utdannede gjetning er at du har to versjoner av tabellen krneki_1, og versjonen uten mellomrom har ikke id_naslov -kolonnen.

Vi eliminerte denne muligheten, det var en kopieringslimfeil fra OP.

  1. Kolonnenavnet i CREATE TABLE og UPDATE er ikke identiske. De kan se like ut, men det kan være tegn som ikke kan skrives ut, eller de kan ha Unicode-tegn som ser like ut, men som er forskjellige kodepunkter. For å finne ut av det, kan vi bruke dette spørsmålet: 

    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" ;

som avslører forskjellen (ikke nødvendige kolonner fjernet fra utdata) : 

+------------+-------------+------------------+----+----+ | 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 | +------------+-------------+------------------+----+----+

Merknad 12 er større enn 10, og det er problemet! Det betyr at kolonnenavnet har 10 tegn og bruker 12 byte. Disse tallene skal begge være 9 (hvis vi teller id_naslov riktig, og hvis alle de 9 tegnene var ASCII), så noe fiskete skjer der.

Du kan legg til hex(column_name) i listen over siste spørsmål, så vet vi nøyaktig hva kolonnenavnet er. Deretter kan du endre det slik at det bare har utskrivbare ASCI-tegn.

For å fikse trenger du noe sånt: 

set @column := X"EFBBBF69645F6E61736C6F76" ; set @qry:= concat("alter table krneki_2 change column ", @column, " id_naslov smallint") ; prepare stmt from @qry ; execute stmt ;

Svar

Problemet kan være at du hadde glemt å utføre en use <database>; -erklæring, og følgelig ikke utførte innsatsen i riktig database.

Med andre ord, du prøver kanskje å sette inn i en tabell som finnes i en annen database, men med en annen struktur.

Svar

Problemet kan være med aliaser i flere div UPDATEs og DELETEs. Jeg har funnet tilfeller der AS k2 ikke fungerer som man forventer. Fjern aliasene og bruk bare tabellnavnene.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *