MYSQL Falscher DOUBLE-Wert abgeschnitten


155

Wenn die folgende SQL-Abfrage ausgeführt wird:

UPDATE shop_category 
SET name = 'Secolul XVI - XVIII' 
    AND name_eng = '16th to 18th centuries' 
WHERE category_id = 4768

Der folgende Fehler wird ausgelöst:

1292 - Truncated incorrect DOUBLE value: 'Secolul XVI - XVIII'

Wie kann ich das beheben?


shop_category Tabellenstruktur:

category_id   mediumint(8)
name        varchar(250)
name_eng      varchar(250)

1
Ist es in irgendeiner Weise bestimmbar, was die wahre Bedeutung dieser Fehlermeldung ist und in welchen Fällen sie angezeigt wird? Da es in Kontexten auftritt, in denen kein DOUBLE-Wert beteiligt ist, scheint es etwas irreführend.
Syck

Vermutlich wird versucht, den BOOLEAN-Wert von 'Secolul XVI - XVIII' vor AND zu berechnen.
Anton Kolyaev

1
Wenn Sie "wo x = 'x' und y" haben, erhalten Sie diesen schlecht konzipierten und undurchsichtigen Fehler
Johan Snowgoose

Antworten:


214

Sie benötigen das ANDSchlüsselwort nicht. Hier ist die korrekte Syntax der UPDATE-Anweisung :

UPDATE 
    shop_category 
SET 
    name = 'Secolul XVI - XVIII', 
    name_eng = '16th to 18th centuries' 
WHERE 
    category_id = 4768

12
Wirklich froh, dass ich diese Antwort gefunden habe, bevor ich den Computer an eine Wand
geworfen habe

19
so definitiv Dummheit von Leuten wie mir, die diesen Fehler machen, aber 'abgeschnittener falscher doppelter Wert' ist eine ziemlich nutzlose Warnmeldung ...
rbennell

6
Grundsätzlich
löst

Ja, ich hatte auch eine ähnliche Erfahrung, als ich versuchte, ein String-Literal in der 'where'-Klausel ohne die Verwendung von Anführungszeichen zu verwenden.
Pranay

Aus diesem Grund wollte ich Selbstmord begehen. Gott sei Dank hast du mein Leben gerettet. Dieses blöde UND im Update. 😠🤣
gauravmehla

72

Ich habe diese Ausnahme nicht wegen UND anstelle von Komma erhalten, sondern weil ich in der where-Klausel keine Apostrophe verwendet habe.

Wie meine Anfrage war

update table set coulmn1='something' where column2 in (00012121);

Als ich die where-Klausel geändert habe, where column2 in ('00012121');hat die Abfrage für mich gut funktioniert.


2
Gleiches Problem für mich! Ich habe versucht, eine Tabelle in einem crm zu aktualisieren, die 1 als Benutzer-ID des Administratorbenutzers und 36 Zeichenführungen für alle anderen Benutzer verwendet. Mein Where gab die user_id als 1 ohne Anführungszeichen an. Ich denke, das hängt damit zusammen, dass sich MySQL im strengen Modus befindet.
Dmulvi

3
@danny_mulvihill Ich glaube, Sie sind auf dem richtigen Weg. Ich hatte ein Feld STRICT_TRANS_TABLESeingerichtet sql_modeund versucht, es zu aktualisieren, das mit einem numerischen Wert in der whereKlausel begrenzt war (was zu sein schien) , und warf einen Fehler auf. Beim Ändern des Modus wurde stattdessen eine Warnung ausgegeben, das Update wurde jedoch nicht angewendet. Bei näherer Betrachtung war die in der where-Klausel verwendete Spalte, obwohl sie nur scheinbar ganzzahlige Werte enthielt, tatsächlich einvarchar(20)
Robert Gannon

Gleiches Problem für mich. Ein 'select * from t where id = 6503' funktionierte einwandfrei, aber 'update t set a = "foo" where id = 6503' führte zu ERROR 1292 (22007): Falscher DOUBLE-Wert abgeschnitten: '234805557438 #'. id sieht aus wie eine ganze Zahl, war aber ein varchar. Das Zitieren des Werts im Update hat das Problem behoben. 'update t set a = "foo" wobei id = "6503"'
gaoithe

Das gleiche Problem für mich beim Übergeben eines INSERT, das in der MySQL-Konsole, aber nicht in der Pentaho Data Integration-Software funktioniert hat. "Name> 1000 und Name <6000" wurde in "Name> '1000' und Name <'6000'" geändert und wirkte wie ein Zauber.
Sawd

13

Versuchen Sie, das ANDdurch zu ersetzen,

UPDATE shop_category 
SET name = 'Secolul XVI - XVIII', name_eng = '16th to 18th centuries' 
WHERE category_id = 4768

Die UPDATE-Syntax zeigt, dass Komma als Trennzeichen verwendet werden sollte.


1
Arbeitete für mich +1 dafür :)
Faisal

12

Was es im Grunde ist

Es ist eine falsche Syntax, die MySQL zu der Annahme veranlasst, dass Sie versuchen, etwas mit einer Spalte oder einem Parameter vom falschen Typ "DOUBLE" zu tun.

Lerne aus meinem Fehler

In meinem Fall habe ich die varchar-Spalte in einer Tabelleneinstellung aktualisiert, in der NULLder Wert 0stand. Meine Update-Abfrage war wie folgt:

UPDATE myTable SET myValue = NULL WHERE myValue = 0;

Nun, da der tatsächliche Typ von myValueist, VARCHAR(255)gibt dies die Warnung:

+---------+------+-----------------------------------------------+
| Level   | Code | Message                                       |
+---------+------+-----------------------------------------------+
| Warning | 1292 | Truncated incorrect DOUBLE value: 'value xyz' |
+---------+------+-----------------------------------------------+

Und jetzt myTableist praktisch leer, denn myValuejetzt ist NULLfür JEDE REIHE in der Tabelle! Wie ist es passiert?
* inneres Schreien *

In über 30.000 Zeilen fehlen jetzt Daten.
* inneres Schreien verstärkt sich *

Gott sei Dank für Backups. Ich konnte alle Daten wiederherstellen.
* interne Schreiintensität sinkt *

Die korrigierte Abfrage lautet wie folgt:

UPDATE myTable SET myValue = NULL WHERE myValue = '0';
                                                  ^^^
                                                  Quotation here!

Ich wünschte, dies wäre mehr als nur eine Warnung, daher ist es weniger gefährlich, diese Zitate zu vergessen.

* Internes Schreien beenden *


1
Sie können eine Option festlegen, die bei Warnungen fehlschlägt - siehe stackoverflow.com/a/4289242/1488762
Roger Dueck

5

Ich habe gerade meine Zeit damit verschwendet und wollte einen zusätzlichen Fall hinzufügen, in dem dieser Fehler auftritt.

SQL Error (1292): Truncated incorrect DOUBLE value: 'N0003'

Testdaten

CREATE TABLE `table1 ` (
    `value1` VARCHAR(50) NOT NULL 
);
INSERT INTO table1 (value1) VALUES ('N0003');

CREATE TABLE `table2 ` (
    `value2` VARCHAR(50) NOT NULL 
);

INSERT INTO table2 (value2)
SELECT value1
FROM table1
WHERE 1
ORDER BY value1+0

Das Problem ist ORDER BY value1+0- Typ Casting.

Ich weiß, dass es die Frage nicht beantwortet, aber dies ist das erste Ergebnis bei Google für diesen Fehler und es sollte andere Beispiele geben, bei denen dieser Fehler auftritt.


4

Hauptsächlich ungültige Abfragezeichenfolgen geben diese Warnung aus.

Falsch aufgrund eines subtilen Syntaxfehlers (falsch platzierte rechte Klammer) bei Verwendung der INSTRFunktion:

INSERT INTO users (user_name) SELECT name FROM site_users WHERE
INSTR(status, 'active'>0);

Richtig:

INSERT INTO users (user_name) SELECT name FROM site_users WHERE
INSTR(status, 'active')>0;

2

Es scheint, dass MySQL das Typ-Casting mit SELECT-Anweisungen elegant handhabt. Das Feld shop_id ist vom Typ varchar, aber die select-Anweisungen funktionieren

select * from shops where shop_id = 26244317283;

Aber wenn Sie versuchen, die Felder zu aktualisieren

update stores set store_url = 'https://test-url.com' where shop_id = 26244317283;

Es schlägt mit Fehler fehl. Falscher DOUBLE-Wert abgeschnitten: '1t5hxq9'

Sie müssen die shop_id 26244317283 in Anführungszeichen '26244317283' setzen, damit die Abfrage funktioniert, da das Feld vom Typ varchar not int ist

update stores set store_url = 'https://test-url.com' where shop_id = '26244317283';

0

Wenn Sie dieses Problem mit einer Beilage erhalten, die wie die folgende aussieht, kann das Problem einfach das Fehlen eines Leerzeichens zwischen --und dem Kommentartext sein:

insert into myTable (a, b, c)
values (
   123 --something
  ,345 --something else
  ,567 --something something else
);

Das Problem dabei ist, dass das --somethingeigentlich -- somethingmit einem Leerzeichen sein sollte.


0

Bei der Verwendung von bindParam und der Angabe von PDO :: PARAM_INT, bei der ich tatsächlich eine Zeichenfolge übergeben habe, ist dieser Fehler aufgetreten. Der Wechsel zu PDO :: PARAM_STR hat den Fehler behoben.


0

Dieser Fehler trat auf, als ich versuchte, WHERE EXIST auszuführen, bei dem die Unterabfrage mit zwei Spalten übereinstimmte, die versehentlich unterschiedlichen Typ waren. Die beiden Tabellen waren auch unterschiedliche Speicher-Engines.

Eine Spalte war ein CHAR (90) und die andere war ein BIGINT (20).

Ein Tisch war InnoDB und der andere war MEMORY.

Teil der Abfrage:

[...] AND EXISTS (select objectid from temp_objectids where temp_objectids.objectid = items_raw.objectid );

Durch Ändern des Spaltentyps für eine Spalte von BIGINT in CHAR wurde das Problem behoben.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.