[MySQL] Load data infile -> 0 rows affected

[Medium]

Moin ihr Recken!

Ich habe hier ein recht wohl geformtes CSV file, wie man es bei Yahoo Finance z.B. hier bekommen kann (ganz unten via "Aufbereitet für Tabellenkalkulationsprogramm"), und möchte dies in meine MySQL tabelle werfen. Dazu verwende ich folgendes Statement:

Code:

LOAD DATA LOCAL
        INFILE 'C:\\Users\\Ich\\Desktop\\DAX30 history\\ADS.csv'
        REPLACE
        INTO TABLE dax30.history
        FIELDS
                TERMINATED BY ','
        LINES
                TERMINATED BY '\r'
        IGNORE 1 LINES
        (`quotedate`, `open`, `high`, `low`, `close`, `volume`, `adjclose`)
        SET symbol = 'ADS.DE';

Das Ergebnis ist eine erfolgreiche Ausführung, aber 0 rows affected, also tabelle leer. Ich habe das FILE Privileg und alles, es gibt eben auch keinen Fehler, aaaaber nix kommt an. Ich habe ein wenig die Befürchtung, dass es mit der einzigen Spalte, die nicht im obigen befüllt wird zusammenhängt. Das ist eine "id" mit auto-inc, die ich aber definitiv brauchen werde.
Daher meine Fagen:
1) Ist meine Vermutung richtig?
2) Wie kann ich das dennoch lösen?

Danke euch im Voraus, und schönen Abend noch!

[blackfin]

Öhm....
REPLACE INTO funktioniert ja an sich wie ein INSERT, ausser, wenn ein Primary Key oder ein Unique Feld doppelt vorhanden wäre.
Das Primary key Feld gibst du ja wie gesagt nicht an, und welches Unique ist, ist anhand der Abfrage nicht ersichtlich.
Ich kann mich täuschen, aber wie soll mySQL nun prüfen, ob der einzufügende Datensatz bereits existiert oder nicht?
Meine Vermutung ist also, durch das Fehlen der Angabe des primary keys (und auch eines unique Felds) gibts keinen Fehler, es passiert aber auch nichts.
(oder...es gibt einen Primary Key UND ein Unique Feld..in dem Fall weiss mySQL auch nicht, was es machen soll.)

Zu erwähnen wäre vielleicht noch, dass "REPLACE INTO" immer einen DELETE und ein INSERT ausführt, wenn ein Datensatz geupdated wird, was stetig den Primary Key zwingt, sich zu reindizieren und intern eben immer zwei aktionen durchführt.
Bei einem "INSERT INTO … ON DUPLICATE KEY UPDATE" passiert das nicht, auch wenn das Statement länger ist und auf den ersten Blick weniger performant aussieht.
In der Realität ist es aber andersrum. Das hat aber nichts mit deinem Fehler zu tun, sondern nur mit der Performance...

P.S.
Poste mal die exakte DDL der Tabelle, dann kruschtel ich auch mal rum

[Medium]

Hey Schwarzfinne!
Es gibt in der Tabelle nur das Feld "id" als primary, sonst keine Indizes. Zudem ist die Tabelle zu diesem Zeitpunkt noch leer.
Die Workbench spuckt mir das folgende sympathisch kompakte Create-Statement aus:

Code:

delimiter $$

CREATE TABLE `history` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `quotedate` datetime DEFAULT NULL,
  `open` decimal(10,4) DEFAULT NULL,
  `high` decimal(10,4) DEFAULT NULL,
  `low` decimal(10,4) DEFAULT NULL,
  `close` decimal(10,4) DEFAULT NULL,
  `adjclose` decimal(10,4) DEFAULT NULL,
  `symbol` varchar(16) DEFAULT NULL,
  `volume` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1$$

Es gibt keinerlei Trigger, keine Stored Procs, einfach nur plain diese Tabelle.

Statt des REPLACE kann man laut Doku auch ein IGNORE oder eben keinen Modifier an dieser Stelle verwenden (macht ja bei leerer Tabelle an sich keinen Unterschied), und ich hab alle 3 Varianten probiert. Alle mit dem selben Ergebnis leider: Kein Fehler, aber auch keine Daten. Danke dir schon mal mächtig!

[jobo]

Ich glaube nicht, dass mySQL das "prüft". Wenn es PK Verletzung gäbe, würde es halt krachen.
Replace in Kombi mit Local ohne PK aus den Importwerten ist vlt. problematisch. Entweder mal auf dem Server probieren, also ohne local oder als PK eine (oder mehrere) Spalten aus den Importwerten verwenden oder Replace weglassen.

[blackfin]

Die DDL ist in Ordnung, kein unique-field, das stören könnte...
Öhm...jetzt mal ne ganz blöde Vermutung, die mir gerade auffällt...normalerweise werden Linux/NIX-Dateien standard-mäßig per Line Feed (\n) terminiert / bzw. eine neue Zeile begonnen,
und nicht, wie bei dir angenommen, durch ein Carriage return (\r)
(...und das Format der dir genannten, wohlgeformten CSV von Yahoo ist definitiv ein NIX-Format)

Probier doch mal einfach das

TERMINATED BY '\r'

durch ein

TERMINATED BY '\n'

zu ersetzen. Nur mal so als blöde Idee...denn das ist meiner Meinung nach nicht ganz richtig in der Abfrage, wenn es ein NIX-Format ist.
(auch wenn als INPUT in tty-Umgebungen ein CR Standard ist, das Dateiformat von NIX-Dateien ist LF-terminiert. So wird das auch mySQL denke ich beim parsen annehmen...)

[Medium]

Ja DAS war ja mal ne Finte! Da das File im Editor ohne Umbrüche angezeigt wurde, in WordPad aber mit, bin ich vom WordPad-Format mit nur \r ausgegangen (irgendwo gelesen, dass dem dort so wäre). Mit einem Linefeed gings! So einfach, und doch so gemein
NIXe Plaintexts bin ich im Editor sonst doch eher mit einem Steuerzeichen aber auch ohne Umbruch am Zeilenende gewohnt - oder ich hab mich nur sehr lange sehr vertan. Mist
Problem gelöst! Danke, Detective Fin!

PS @jobo: Ist auf dem Server, hatte ich vergessen zu erwähnen. Sorry!