RootForum Community

Hallo an alle User in diesem Forum.

Ich habe ein Problem, dass ich eine bestehende Datenbank per .txt oder.csv Datei updaten will.
Ich mache das ganze über ein phpmyadmin interface, wo ich direkt in die sql maske den entsprechenden Befehl dafür eingebe. Die .csv Datei liegt auf meinem Server, wo auch die Datenbank läuft, unter dem Verzeichniss: /home/www/web6/html/test/test.csv
Leider bekomme ich immer nur eine Fehlermeldung und habe das gefühl, dass er die Datei auch nicht findet.

Mein Sql Befehl:

LOAD DATA INFILE '/home/www/web6/html/test/boems.csv' REPLACE INTO TABLE `katalog`
FIELDS TERMINATED BY ';'
ENCLOSED BY '"'
ESCAPED BY '\\'
LINES TERMINATED BY 'n'(

`best` ,
`instrument` ,
`buch` ,
`autor` ,
`titel` ,
`isbn` ,
`ismn` ,
`preis` ,
`bild` ,
`text` ,
`neu`
)

Die Fehlermeldung:

Field separator argument is not what is expected. Check the manual

Ich hoffe ihr könnt mir da weiterhelfen.

Tag,

RTFM: http://www.mysql.com/doc/en/LOAD_DATA.html

In MySQL 3.23.49 and MySQL 4.0.2 LOCAL will only work if you have not started mysqld with --local-infile=0 or if you have not enabled your client to support LOCAL. See section 4.2.4 Security issues with LOAD DATA LOCAL.

bye
arty

Diesen Teil der Docu habe ich auch schon gelesen, aber ich weiss nicht was ich machen muss, damit ich es zum laufen bringe. Ich bin neu im umgang mit linus ( suse ) und habe keine ahnung, ob man jetzt mysql neu kompilieren muss, oder nur im run script den Parameter mysqld --local-infile=1 hinzufügen muss.

Ich bedanke mich jetzt schon mal, für eure Bemühungen.

Hi,

das musste im Startskript ändern, neu kompilieren ist nicht nötig.

bye
Thorsten

Das ist ja schon mal super. Hauptsache nicht kompilieren. Jetzt weiss ich aber immer noch nicht wie und wo ich diese Ergänzung hineinschreiben muss ( in welches Runlevel und in welcher File an welcher Stelle ).

Hi,

da dein Server ja wohl nur im Runlevel 3 läuft, musste das dort ändern. Aber wo genau, das weiß ich nicht.

bye
arty

Vielleicht weiss ja jemand anders wo ich das ändern muss. Ich habe schon in vielen scripten gesucht, wo der mysqld aufruf kommt, aber nicht gefunden.

kc1441 wrote:Vielleicht weiss ja jemand anders wo ich das ändern muss.

Die Startscripte liegen alle (soweit ich mich noch an die SuSE Zeit erinnern kann :-D ) in /etc/init.d und sind dann nur in die Runlevel gelinkt.
Du musst also in /etc/init.d/mysql(d) die Ã?nderungen vornehmen und dann den SQL Server mittels /etc/init.d/mysql(d) stop und /etc/init.d/mysql(d) start oder /etc/init.d/mysql(d) restart neu starten. Dann sollte es funktionieren.

Ich denke auch dass in diesem script die Ã?nderung gemacht werden muss, ich habe mir das auch schon angeschaut, aber leider ist es für mich nicht eindeutig an welcher Stelle ich was ändern muss.

Ich habe mal mein Script zum download zur verfügung gestellt, veilleicht kann mir ja eine von euch sagen, wo und was.

Danke

http://www.loomconcept.de/test/mysql

Ich würde einfach folgendes machen:

direkt vor würde ich folgendes hinzufügen:

ich habe es versucht an dieser Stelle einzufügen, aber leider ohne erfolg. Ich bekomme dann eine Fehlermeldung, dass mysqld schon gestartet ist.

Dann folgendes abändern: in Achtung: Kommt mehrmals in start vor.
Sag bescheid, ob das jetzt funtioniert hat (auch stop, restart etc testen)

Ich habe jetzt beide Bereiche durch deinen neuen Tag ersetzt, aber jetzt spuckt er mir wieder eine Fehlermeldung aus.

Restarting service MySQL
Shutting down service mysql
done
Starting service MySQL
/etc/init.d/mysql: line 183: --local-infile=1: command not found
Starting mysqld daemon with databases from /var/lib/mysql

Ich denke mal der Fehler bezieht sich auf den 2.ten Bereich unter dem punkt start. Ich habe mal die Zeilen mir angeschaut und 183 ist der zweite Tag.

Jetzt stellt sich die Frage ob er das erste auch eingelesen hat und mysql mit dem neuen Parameter gestartet hat?

kc1441 wrote:/etc/init.d/mysql: line 183: --local-infile=1: command not found

Komisch, dass er die Option als Befehl behandelt. Bist du dir sicher , dass du die (Backslashes) alle hast??

kc1441 wrote:Starting mysqld daemon with databases from /var/lib/mysql

Scheint ja trotzdem zu laufen

kc1441 wrote:Ich denke mal der Fehler bezieht sich auf den 2.ten Bereich unter dem punkt start.

Ja, tut er. Der erste Bereich wird nur aufgerufen, wenn noch keine Datenbanken erstellt wurden, also mySQL zum ersten Mal gestartet wird.

kc1441 wrote:mysql mit dem neuen Parameter gestartet hat?

Vermutlich eher nicht, da er die Option als Shell Befehl interpretiert hat.

Du hattest recht ich habe etwas mit dem falsch gemacht. Ich habe es jetzt nochmal korrekt eingefügt, und mysql startet ohne das es eine Fehlermeldung ausgibt. Leider bekomme ich aber bei dem Import von einer Datei immernoch die Fehlermeldung, die ich oben schon mal beschrieben habe. Also an dem eigentlichen Problem hat sich leider nix geändert. Kann es sein das es an meiner MYSQL Version liegt, dass es nicht geht?
Seit dem ich meinen Server auf Linux 8.1 geupdatet habe, also neu aufsetzen lassen habe, geht das nicht mehr, was vorher kein Problem gemacht hat.

kann es sein das die Befehle nicht in der mysql eingetragen werden müssen, sondern in my.cnf die in /etc steht?

Ich habe da so ein Thread gelesen in einem anderem Forum. Es kann doch einfach nicht angehen, dass man in jedem Forum das gleiche Problem liest, aber in keinem eine wirkliche Lösung dafür angeboten wird. Alle verweisen immer auf die Doku von Mysql, aber da steht leider auch in keiner weise, wo man die Ã?nderungen machen muss.

Das sollte im Prinzip egal sein. Beim Starten von mysqld wertet dieser sowohl die direkt übergebenen Parameter (z.B. aus dem Startscript) als auch die in der my.cnf aus.

Ich habe gerade in einem anderem Forum gelesen, dass es wohl garnicht geht diese Funktion zu aktivieren, wenn man nicht bei der installation von mysql beim compilieren den korrekten Parameter mit angegeben hat.

Bsp.: ./configure --enable-local-infile

Sollte dies der Fall sein, dann habe ich natürlich ein Problem, weil ich nicht weiss wie ich meine Datenbanke backupen kann und sie dann auch wieder in der neu compilierten Version wieder einspielen kann. Abgesehen davon, dass auch das compilieren mir nicht einfach von der Hand gehen wird.

Was sagt Ihr dazu?

Ich habe das gleiche Problem auf den Rootservern die neuaufgesetzt worden sind.
Nachdem ich nun über eine Stunde auf mysql.com und in zahlreichen anderen Foren nach einer Lösung gesucht habe, sieht es wohl so aus, als ob ich das ganze neu compilieren muss. Meine Frage ist nun aber, wie genau mache ich das nun wieder. Ich meine das Compilieren der Source Datei werde ich sicher hinbekommen, nur was ist mit all den anderen "programmen" die man sonst als RPM noch dazu installieren muss?
z.B.:
mysql-3.23.53-26.i386.rpm
mysql-bench-3.23.53-26.i386.rpm
mysql-client-3.23.53-26.i386.rpm
mysql-devel-3.23.53-26.i386.rpm
mysql-shared-3.23.53-26.i386.rpm

Compiliere ich nun nur den mysqld und die anderen kann ich die rpms nehmen, oder muss ich die anderen auch selbst compilieren?

Würde mich über eine Antwort freuen.

wie gross ist denn die csv datei?
kannst Du diese nicht mit phpmyadmin einlesen und gut is?
oder einen vollständigen dump generieren und mit
mysql database < dateiname einlesen?
mysql -u root -p123456 datenbank < '/srv/www/htdocs/datei.sql';

nur mal so als alternative :-)

sicher wäre das auch eine lösung! Aber auf dauer ist dies für mich nicht die richtige. Ich möchte das auch ohne Umwege machen können. Weiterhin finde ich es auch interessant hierfür eine Lösung zu finden. Besonders da man in den mysql.com Foren sehen kann das dieses Problem nicht nur bei einigen Auftritt, sondern bei vielen Leuten.

Genau das Problem habe ich auch. Ist das Problem in alles mysql versionen und gibt es eine neue version die das kann?
Verstehe sowieso nicht warum dieser befehl nicht geht. wenn einer was raus hat bitte hier reinposten. :)

Das Problem ist, dass diese Funktion als super gefährlich und sicherheitsmässig als Lücke deklariert ist.

Ich kann zwar nachvollziehen, das Sicherheitslücken geschlossen werden sollten. Aber es sollte jedem freigestellt sein, diese Lücke wieder einzubauen ;)

Ja, es ist bei jeder neueren MYSQL-Version so!

Nun aber genug geschwafelt.

Wer hat es denn nun schonmal geschafft MYSQL mit der Option zu compilieren? Ich scheitere daran. Ein HowTo wäre supi!

Bittteeeeeeeee! Wer kann MYSQL compilieren? Wer schreibt eine kleine FAQ?

schade das es hierfür immernoch keine Lösung gibt.

Es muss doch in der zwischenzeit mal jemanden geben, der weiß wie man das beheben kann.

Hi,

also ich habe kein local einkompiliert, und die Zeile
funktioniert, seitdem ich den Parameter "-L" eingefügt habe. Wenn ich den mysql-Client mit "--local-infile" starte, funktioniert das bei mir auch:
Grüße,

flo.