12
LOAD DATA LOCAL INFILE . INTO TABLE
Hallo,
ich importiere mit diesem Behfel eine CSV-Datei mit Daten in eine Tabelle von PHPmyAdmin:
Die CSV Datei hat folgenden Aufbau:
Tabllenstruktur in PhpmyAdmin:
Ich will nun erreichen, dass der Befehl nicht ausgeführt wird, wenn z.B. im Feld "tel_ID" etwas anderes als eine Zahl steht, sprich bei "INSERT" Fehlern soll abgebrochen werden.
Wie erreiche ich das?
Gruß und Vielen Dank!
ich importiere mit diesem Behfel eine CSV-Datei mit Daten in eine Tabelle von PHPmyAdmin:
LOAD DATA LOCAL INFILE \" /home/myuser/Schreibtisch/Datei.csv\" INTO TABLE xxxx CHARACTER SET 'utf8' FIELDS TERMINATED BY ';' Die CSV Datei hat folgenden Aufbau:
1;Müller;Max;789Tabllenstruktur in PhpmyAdmin:
Ich will nun erreichen, dass der Befehl nicht ausgeführt wird, wenn z.B. im Feld "tel_ID" etwas anderes als eine Zahl steht, sprich bei "INSERT" Fehlern soll abgebrochen werden.
Wie erreiche ich das?
Gruß und Vielen Dank!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 362749
Url: https://administrator.de/contentid/362749
Printed on: April 23, 2024 at 11:04 o'clock
12 Comments
Latest comment
Moin.
Hallo ? Bei INSERT Fehler abbrechen
Der ist gerade mal 18h alt (abzüglich SONNTAGSzeit...)
...immer noch stehts im Handbuch: MySQL-Reference 13.2.6 LOAD DATA INFILE Syntax
~Arano
Hallo ? Bei INSERT Fehler abbrechen
Der ist gerade mal 18h alt (abzüglich SONNTAGSzeit...)
...immer noch stehts im Handbuch: MySQL-Reference 13.2.6 LOAD DATA INFILE Syntax
Zitat weggelassen, weil steht ja eh im Link
~Arano
Hi @Arano
finds echt nett das du dich um mein Problem kümmerst aber ich habe diese Seite selbst heute mehrmals besuch und gelesen....
Alles was ich daraus ableiten kann ist jedoch nur, dass ich mit dem IGNORE Befehl die Fehler überspringe.... ich will ja exakt das Gegenteil.
Sorry bin auch kein MQSQL Fuchs...
finds echt nett das du dich um mein Problem kümmerst aber ich habe diese Seite selbst heute mehrmals besuch und gelesen....
Alles was ich daraus ableiten kann ist jedoch nur, dass ich mit dem IGNORE Befehl die Fehler überspringe.... ich will ja exakt das Gegenteil.
Sorry bin auch kein MQSQL Fuchs...
Na,
Da du in den anderen Fragestellungen immer mal selbiges aus einer Bash-Datei herraus machst, nehme ich mal an das du lokal auf deinem Rechner arbeitest ?
Wenn das so ist, solltest du das LOCAL in deinem Statement auch weglassen können. Damit sollte die Fehlerbehandlung wieder möglich sein.
Warum und weiso ...steht in der Reference die verlinkt wurde. ;)
Zugegeben ich mach das auch nicht immer, aber man sollte sich mit den Befehlen und Kommandos die man so verwendet schon auseinander setzen/einlesen. Denn blindes vertrauen/probieren kann auch mal im totalen Datenverlust enden.
~Arano
finds echt nett das du dich um mein Problem kümmerst
Na wie gesagt, helfen tun wir ja gerne. LOCAL also affects error handling:
- With LOAD DATA INFILE, data-interpretation and duplicate-key errors terminate the operation.
- With LOAD DATA LOCAL INFILE, data-interpretation and duplicate-key errors become warnings and the operation continues because the server has no way to stop transmission of the file in the middle of the operation. For duplicate-key errors, this is the same as if IGNORE is specified. IGNORE is explained further later in this section.
Da du in den anderen Fragestellungen immer mal selbiges aus einer Bash-Datei herraus machst, nehme ich mal an das du lokal auf deinem Rechner arbeitest ?
Wenn das so ist, solltest du das LOCAL in deinem Statement auch weglassen können. Damit sollte die Fehlerbehandlung wieder möglich sein.
Warum und weiso ...steht in der Reference die verlinkt wurde. ;)
Zugegeben ich mach das auch nicht immer, aber man sollte sich mit den Befehlen und Kommandos die man so verwendet schon auseinander setzen/einlesen. Denn blindes vertrauen/probieren kann auch mal im totalen Datenverlust enden.
~Arano
Moin,
also wenn tel_id tatsächlich als PRIMARY und (logischerweise ) mit NOT NULL definiert ist, dann glaub ich nicht das mysql hier eine Zeile importiert und das Feld leer lässt - sowie das in deinem anderen Post behauptet wird.
Was man aber machen kann: (Pseudocode, da ich den mysql Syntax nicht genau kenne)
1. Import in Temp-Tabelle die in der Struktur der orginal Tabelle gleicht, in der aber alle Felder NULL sein können.
2. Transaktion starten
3. INSERT INTO original Tabelle SELECT FROM Temp-Tabelle
4. Bei Fehler -> Rollback
5. Kein Fehler -> Commit
lg,
Slainte
also wenn tel_id tatsächlich als PRIMARY und (logischerweise ) mit NOT NULL definiert ist, dann glaub ich nicht das mysql hier eine Zeile importiert und das Feld leer lässt - sowie das in deinem anderen Post behauptet wird.
Was man aber machen kann: (Pseudocode, da ich den mysql Syntax nicht genau kenne)
1. Import in Temp-Tabelle die in der Struktur der orginal Tabelle gleicht, in der aber alle Felder NULL sein können.
2. Transaktion starten
3. INSERT INTO original Tabelle SELECT FROM Temp-Tabelle
4. Bei Fehler -> Rollback
5. Kein Fehler -> Commit
lg,
Slainte
Okay, verstanden!
Problem ist jetzt nur, bekomme bei Ausführung die Fehlermeldung:
The MYSQL Server is running with the --secure-file-priv option so it cannot execute this statement
Aber das ist ja wieder ein anders Problem. Trotzdem danke ich dir!
Problem ist jetzt nur, bekomme bei Ausführung die Fehlermeldung:
The MYSQL Server is running with the --secure-file-priv option so it cannot execute this statement
Aber das ist ja wieder ein anders Problem. Trotzdem danke ich dir!
Na,
...lass es uns doch mal probieren:
Also ich bekomme diese Meldung auch und habe die Option auf NULL stehen.
Aber das ist keine Fehlermeldung, das ist eine Sicherheitseinrichtung ! <-- Wichtig, nicht böse
~Arano
also wenn tel_id tatsächlich als PRIMARY und (logischerweise ) mit NOT NULL definiert ist, dann glaub ich nicht das mysql hier eine Zeile importiert und das Feld leer lässt - sowie das in deinem anderen Post behauptet wird.
Ging mir auch schon durch den Kopf das es doch krachen müsste oder es irgendeine Art Typen-Cast gibt....lass es uns doch mal probieren:
mysql> create temporary table newit (id int, vname char(30), primary key (id));
mysql> insert into newit value( 1, 'hallo'),(2,'wer');
[17:58]arano:~$ cat newit.sql
a;arano
4;newit
[18:05]arano:~$
mysql> load data local infile '/home/arano/newit.sql' into table newit fields terminated by ';';
Query OK, 2 rows affected, 1 warning (0,00 sec)
Records: 2 Deleted: 0 Skipped: 0 Warnings: 1
mysql> select * from newit;
+----+-------+
| id | vname |
+----+-------+
| 0 | arano |
| 1 | hallo |
| 2 | wer |
| 4 | newit |
+----+-------+
4 rows in set (0,00 sec)
mysql> exit
Byemysql> load data infile '/home/arano/newit.sql' into table newit fields terminated by ';';
> ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statementAber das ist keine Fehlermeldung, das ist eine Sicherheitseinrichtung ! <-- Wichtig, nicht böse
mysql> select @@global.secure_file_priv;
+---------------------------+
| @@global.secure_file_priv |
+---------------------------+
| NULL |
+---------------------------+
1 row in set (0,00 sec)
mysql>MySQL-Reference
secure_file_priv may be set as follows:
Also bleibt die Wahl zwischen dem Ändern der Serverkonfiguration oder dem Zeilenweisen Import der Datensätze.secure_file_priv may be set as follows:
- If empty, the variable has no effect. This is not a secure setting.
- If set to the name of a directory, the server limits import and export operations to work only with files in that directory. The directory must exist; the server will not create it.
- If set to NULL, the server disables import and export operations. This value is permitted as of MySQL 5.7.6.
~Arano
1
Moin,
Kann man nicht dafür sorgen, dass die zu importierende Quelldatei bereits bereinigt ist?
Schlimmstenfalls die ursprungsdatei Zeilenweise auslesen, das erste Feld mit IsDigit/ IsNum (hängt von der verwendeten Scriptsprache ab) das erste Feld prüfen. Wenn IsDigit== true, dann in die neue Importdatei, wenn ==false, dann in eine errordatei.
Dann weisst du auch direkt, welche Daten "strubbelig" sind.
In Summe zwar aufwendiger, aber auch solider.
Gruß
em-pie
Kann man nicht dafür sorgen, dass die zu importierende Quelldatei bereits bereinigt ist?
Schlimmstenfalls die ursprungsdatei Zeilenweise auslesen, das erste Feld mit IsDigit/ IsNum (hängt von der verwendeten Scriptsprache ab) das erste Feld prüfen. Wenn IsDigit== true, dann in die neue Importdatei, wenn ==false, dann in eine errordatei.
Dann weisst du auch direkt, welche Daten "strubbelig" sind.
In Summe zwar aufwendiger, aber auch solider.
Gruß
em-pie
1Finds aber allgemein trotzdem sehr komisch das MySql das durchgehen lässt, wenn ich einen Numerischen Datentyp eingestellt habe....naja
Poste doch bitte mal den Output von DESCRIBE <name der import tabelle>
MySQL kann hier nichts "durchgehen lassen", sonst wäre das komplette RDBMS für die Katz...
MySQL lässt so einiges durchgehen und hat nicht überall den besten Ruf. Du kannst z.B. CHECK Constraints ersellen, sie werden nur nicht beachtet. Du konntest in alten Versionen syntaktisch falsche Selects mit Group By absetzen und es gab keine Fehlermeldung sondern ein (zufälliges) Ergebnis...
