Große CSV-Datei serverseitig in DB einspielen

[Eddie]

Hallo allerseits,

vielleicht koennt ihr mir dabei helfen: ich versuche gerade, einen etwas größeren DB-Dump in meine MySQL-DB zu bekommen. Bisher habe ich das immer über ein Webformular meiner DB-Verwaltung (PHPMyAdmin) gemacht, nur ist diese Datei dafür etwas zu groß.
Wie mache ich das serverseitig?

Danke für eure Hilfe,
Eddie

[kai]

hi,

also bei grossen dateien mach ich das immer über ein php script,
was einfach alle zeilen ausliest und in die db schreibt..
solang du keinen zugang zur mysql konsole hast bleibt dir auch nicht
viel anderes übrig ...

cu
kai

[Säbelzahnigelchen]

Hi,

vielleicht koennt ihr mir dabei helfen: ich versuche gerade, einen etwas größeren DB-Dump in meine MySQL-DB zu bekommen. Bisher habe ich das immer über ein Webformular meiner DB-Verwaltung (PHPMyAdmin) gemacht, nur ist diese Datei dafür etwas zu groß.

wenn die datei [b]etwas[/b] zu gross ist, hast Du immerhin ein workaround. :)

Wie mache ich das serverseitig?

Rechte einraeumen lassen und die gut dokumentierte Schnittstelle zum Massenimport von Daten nutzen. - Sofern MySQL sowas hat. Aber das liesse sich ermitteln.

MFG
Säbelzahnigelchen

[Säbelzahnigelchen]

Wie mache ich das serverseitig?
Rechte einraeumen lassen und die gut dokumentierte Schnittstelle zum Massenimport von Daten nutzen. - Sofern MySQL sowas hat. Aber das liesse sich ermitteln.

Habe noch sowas gefunden:
http://dev.mysql.com/doc/refman/5.1/de/mysqlimport.html
http://dev.mysql.com/doc/refman/5.1/de/load-data.html

Wobei ich jetzt vergessen habe, ob die Version konveniert...

[Eddie]

Hallo Säbelzahnigelchen,

cool, das hat mir schon sehr geholfen - die Daten bekomme ich jedenfalls rein.

Allerdings bekomme bei meiner Testdatei ich die Meldung:
   Records: 43651  Deleted: 0  Skipped: 0  Warnings: 1931

Nur wie kann ich mir jetzt die Warnungen anzeigen lassen???

Versucht habe ich es mit
   --verbose und
   --debug='d:t:o,fehler.txt' (wie beschrieben)

Hat leider beides nicht funktioniert :-(

Hast du da eine Idee?

Eddie

[silver Karnickel]

Hi,

Versucht habe ich es mit
   --verbose und
   --debug='d:t:o,fehler.txt' (wie beschrieben)

Hat leider beides nicht funktioniert :-(

könnte natürlich ein Rechteproblem sein. Hat der account, unter dem der mysql-Daemon gefahren wird, die benötigten Rechte die Datei zu schreiben? (Wo eigentlich?)

silver Karnickel

[Eddie]

Hallo!

könnte natürlich ein Rechteproblem sein. Hat der account, unter dem der mysql-Daemon gefahren wird, die benötigten Rechte die Datei zu schreiben? (Wo eigentlich?)

Ja, geht! Ich bin über SSH drin und kann selbst zumindest Dateien anlegen. Aber ich habe den Verdacht, dass das Debugging garnicht zur Verfügung steht :-/ Keine Ahung, wie ich das feststellen kann...

Aber einen Fehler habe ich jetzt zumindest mal durch Stichproben rausgefunden: ein nicht passender Wertebereich wegen signed-Attributen. Dadurch habe ich die Warnings auf die Haelfte reduziert. Es geht voran... ;-)

Gruss,
Eddie

[Sgt. Redrum]

Hi,

Aber einen Fehler habe ich jetzt zumindest mal durch Stichproben rausgefunden: ein nicht passender Wertebereich wegen signed-Attributen. Dadurch habe ich die Warnings auf die Haelfte reduziert. Es geht voran... ;-)

ich empfehle erst einmal eine SQL-Tabelle zu erstellen, die alle Daten sicher aufnimmt, also mit ausschliesslich CHAR-Datenfeldern.

Dann machst Du den Datentransfer.

Dann kannst Du mit "ISNUMERIC()" und "ISDATE()" und ähnlichen Funktionen die Datensätze dieser Tabelle prüfen und "Stück für Stück" die wirkliche schon existierende Zieltabelle füllen.

Dein Problem sind die unpassenden Werte, also schnell mit den Daten in die SQL-Welt und dort weiterbearbeiten.

Sgt. Redrum

[Eddie]

Hi Danny ;-)

ich empfehle erst einmal eine SQL-Tabelle zu erstellen, die alle Daten sicher aufnimmt, also mit ausschliesslich CHAR-Datenfeldern.

Ok, genauso hab ich's jetzt gemacht!

Dann kannst Du mit "ISNUMERIC()" und "ISDATE()" und ähnlichen Funktionen die Datensätze dieser Tabelle prüfen und "Stück für Stück" die wirkliche schon existierende Zieltabelle füllen.

Ich (bzw. phpMyAdmin) hab mir jetzt damit beholfen, das ging auf einen Schlag:

SELECT *
   FROM MyTable
   PROCEDURE ANALYSE ( )

Danke dir,
Eddie

[Vinzenz Mai]

Hallo Eddie,

vielleicht koennt ihr mir dabei helfen: ich versuche gerade, einen etwas größeren DB-Dump in meine MySQL-DB zu bekommen.

nur mal am Rande gefragt: welche MySQL-Version steht Dir inzwischen zur Verfügung? Immer noch die 4.0.x? Oder hast Du jetzt eine neuere?

Freundliche Grüße

Vinzenz

[Eddie]

Hallo Vinzenz,

nur mal am Rande gefragt: welche MySQL-Version steht Dir inzwischen zur Verfügung? Immer noch die 4.0.x? Oder hast Du jetzt eine neuere?

Ja, leider :-/ Ich habe "nur" einen ManagedServer, der kostet mich zwar mehr Geld, dafür kann ich aber nicht mitentscheiden...

Eddie

[Eddie]

Hallo nochmal,

nur mal am Rande gefragt: welche MySQL-Version steht Dir inzwischen zur Verfügung? Immer noch die 4.0.x? Oder hast Du jetzt eine neuere?

Ich guck immer mit phpInfo() nach, vermute mal, dass ich dort auch alle relevanten Infos kriege? Jedenfalls heißt es dort (unter "mysql":

Client API version: 4.0.25

Das ist die Angabe, oder?

Eddie

[dedlfix]

echo $begrüßung;

nur mal am Rande gefragt: welche MySQL-Version steht Dir inzwischen zur Verfügung? Immer noch die 4.0.x? Oder hast Du jetzt eine neuere?
Ich guck immer mit phpInfo() nach, vermute mal, dass ich dort auch alle relevanten Infos kriege? Jedenfalls heißt es dort (unter "mysql":

Client API version: 4.0.25

Das ist die Angabe, oder?

Nein. Wenn die Client-API-Version mit der Version des Servers übereinstimmt ist das Zufall. Wie soll phpinfo(), dass keine Verbindung zu irgendeinem MySQL-Server aufbaut, dessen Version herausbekommen? Dazu muss man schon den jeweiligen Server selbst fragen: SELECT VERSION() oder mysql_get_server_info() nach einem erfolgreichen Verbindungsaufbau.

echo "$verabschiedung $name";

[Eddie]

Hallo $name,

ok, danke dir! Hat sich aber bestätigt, SELECT VERSION() ergibt:

4.0.25-standard

Eddie