CSV import in Mysql

Feather

Grünschnabel
Servus,

vor einiger Zeit konntet Ihr mir schon recht gut mit einem Problem helfen, welches eigentlich nur durch Flüchtigkeit entstanden ist.

Heut hab ich nochmal n Problem, bei dem ich einfach nicht weiterkomme.

Für unseren Betrieb schrieb ich eine kleine Anwendung, welche Daten aus einer CSV importiert und in einer MYSQL-DB ablegt.

Funktioniert wunderbar und ist richtig toll - blöd ist nur das dass Datenende der Datei nicht zum stoppen des Scriptes führt.

Besser gesagt: Ruft man das per Link auf, dann schon - aber nicht wenn es im Cron aufgerufen wird.

Könnt Ihr mir vielleicht helfen? Sitze hier schon (gefühlt) Ewigkeiten ohne eine nennenswerte Lösung gefunden zu haben. :/

PHP:
    $file = $_FILES[csv][tmp_name];
   
        $handle = fopen("./export/import.csv","r") or die ("Kann Datei nicht lesen.");
 
    do {
        if ($data[0]) {
            mysql_query(" UPDATE products SET stock = '".addslashes($data[1])."' WHERE picture =  '".addslashes($data[0])."'

            ")or die(mysql_error();
        }
    }
 
    while (($data = fgetcsv($handle,25, ",")) !== FALSE);

    fclose($handle);

    header('Location: import.php?success=1'); die;

Vielen Dank im voraus :))
 
Hi

heißt das, es werden unendlich viele weitere Zeilen eingefügt (mit welchem Inhalt)? Oder...?

Jedenfalls sollte das Script in der Form gar nicht funktionieren. Der Reihe nach:

Wofür ist $file ?

Bei Arrayindizes wie csv und tmp_name gehören Anführungszeichen dazu.

Beim ersten Schleifendurchgang gibt es noch kein $data, also kann es auch nicht verwendet werden.

addslashes ist nicht genug, um Sql-Injections zu verhindern - dafür gibt es andere, bessere Funktionen (abhängig davon, wie man generell auf die DB zugreift).

Die mysql_* - Funktionen gibts generell nicht mehr, sollten also auch nicht funktionieren.
 
Servus sheel,

Danke für Deine Antwort :)

$file habe ich entfernt, das war noch ein Rest aus einem anderen Script, den ich bislang missachtet habe.
Müsste fgetcsv dann eigentlich nach oben gezogen werden?

Statt "addslashes", welche Funktion sollte man stattdessen verwenden um SQL-Injektionen zu verhindern?
Das Script ist nicht live sondern läuft nur intern auf einer Diskstation - Du hast aber völlig Recht das zu kritisieren wenn es faktisch unsicher ist.
Ich greife per vorgelagertem Connect-String in dem PHP-Script auf die Datenbank zu. Das ist sicher auch nicht die beste Art eine Verbindung aufzubauen oder?

Ab welcher Version gibt es diese Funktion nicht mehr? (mysql_*) Oder soll man das grundsätzlich nicht verwenden?

Vielen Dank vorab und viele Grüße :)
 
Müsste fgetcsv dann eigentlich nach oben gezogen werden?
Das versteh ich nicht ganz. Wenn du meinst, du willst eine while-Schleife statt do-while, wo die Bedingung "oben" ist, dann ja.

Statt "addslashes", welche Funktion sollte man stattdessen verwenden um SQL-Injektionen zu verhindern?
Hängt davon ab, wie man auch die DB zugreift. Für die gezeigten mysql_* - Funktionen gibt es mysql_real_escape_string.

Ab welcher Version gibt es diese Funktion nicht mehr? (mysql_*) Oder soll man das grundsätzlich nicht verwenden?
Wirklich weg sind sie seit Version 7.0.0. von PHP, 2015 veröffentlicht. Es wurde davor aber auch schon einige Jahre gewarnt, dass man die Funktionen nicht mehr einsetzen soll, weil sie eben bald weg sind.
Version 5.6 (mit den Funktionen) hat zwar aktuell noch für ein paar Monate Sicherheitsupdates, falls was gefunden wird, aber dann ist auch die letzte Version mit den Funktionen offiziell beendet. (Warum man Software ohne Sicherheitsupdates nicht im offenen Internet laufen lassen soll ist vermutlich klar...)

Jetzt kann man für Mysql-DBs entweder die Mysqli - Funktionen verwenden, die relativ ähnlich zu den alten sind (aber nicht gleich!), oder PDO (andere Funktionen. Zielt mehr darauf ab, mehrere DBs zu unterstützen, und kann dafür nicht alle Mysql-Spezialsachen).
Mysqli kommt selbst in zwei Varianten, a) Funktionen, b) strukturiert in Klassen. Wenn man sich vor Klassen nicht fürchtet ist letzteres einfacher.

Für Mysqli gibt es auch eine real_escape-Funktion gegen Injections.

Ich greife per vorgelagertem Connect-String in dem PHP-Script auf die Datenbank zu. Das ist sicher auch nicht die beste Art eine Verbindung aufzubauen oder?
Solange Seitenbesucher etc. den nicht sehen, kein Problem. Wirklich viel sinnvolle Alternativen gibts auch nicht.
 
Zurück