nicht angemeldet
Rolf B
Rolf B
Tabellenkalk
dedlfix
klawischnigg
Tabellenkalk
dedlfix
Tabellenkalk
dedlfix
klawischnigg
Camping_RIDER
Rolf B
dedlfix
Tabellenkalk
Hallo,
ich habe eine CSV Datei, diese hat folgenden Inhalt
"1;;Test Eintrag, weiß;weiß;Tisch-Rund, weiß 04/01/001;0,5;0,55;1,1;49;;15;L1;;;20;;;;;;"
Diese möchte ich über den phpMyAdmin einspielen
Wenn ich diesen ausführe, erhalte ich folgende Meldung
Allerdings es ist nichts in der Datenbank. Wo landen die Einträge? Oder mache ich irgendetwas falsch?
Eine CSV Datei -- Eine Tabelle. Suche die Tabelle!
Ich bin ja schon in der Tabelle und sage dort importieren. Fehlermeldung erhalte ich keine nur der Datensatz taucht nicht auf.🧐
Hallo Bernd,
Fehlermeldung erhalte ich keine
Aber auch keine Erfolgsmeldung. "0 Zeilen importiert" ist irgendwie verdächtig.
Hat die Zeile der CSV Datei ein Anführungszeichen ganz am Anfang und am Ende der Zeile, und sonst nirgends? In dem Fall wäre diese Zeile ein einziger String, weil Du ja „Spalten eingeschlossen mit: " “ angegeben hast.
Ich hätte allerdings einen Fehler erwartet, dass "1;;Test Eintrag, weiß;weiß;Tisch-Rund, weiß 04/01/001;0,5;0,55;1,1;49;;15;L1;;;20;;;;;;" nicht numerisch ist (vermutlich ist die 1 deine ID). Oder dass die CSV Datei nicht soviele Spalten hat wie die DB.
Ist ein Zeilenumbruch am Ende der Zeile? Möglicherweise verwirrt ihn das. Ich weiß nicht wie sensibel phpMyAdmin da ist.
Irgendwas ist faul im Staate Berndemark. Was - das ist im Moment schwer zu sagen.
Rolf
Ich würd sagen, wenn die Daten nicht ankommen und kein Fehler gemeldet wurde, ist die Anwendung unbrauchbar.
Hallo pl,
ok. Stelle uns deine Alternative zu phpMyAdmin vor.
Rolf
Ich mache sowas auf der Kommandozeile!
Hallo pl,
du hostest die DB ja auch in deiner eigenen Hosentasche. :)
Frage ist, ob Bernd das auch tut. Ein Webspace-Hoster hustet dir was, wenn Du remote direkt an der DB rumgrabbeln willst.
Rolf
Frage ist, ob Bernd das auch tut. Ein Webspace-Hoster hustet dir was, wenn Du remote direkt an der DB rumgrabbeln willst.
Ich rede ja auch von HTTP und RPC.
Ein Webspace-Hoster hustet dir was, wenn Du remote direkt an der DB rumgrabbeln willst.
Nicht jeder. Bei meinem geht das. Man kann die Verbindung aber auch tunneln, was bei vielen Hostern gehen sollte, die ssh anbieten, aber keinen direkten Zugang zur Datenbank und das halt nur nicht beschreiben...
Hallo,
nein, ich habe kein Server sondern nur ein Webspace bei all-inkl. Ein eigener Server trau ich mich nicht zu, dieser muss ständig aktuell gehalten werden usw.
Hallo,
Oder mache ich irgendetwas falsch?
Auf jeden Fall ists flasch, zu behaupten, die Spalten wären in „"“ eingeschlossen, wenn sie es offensichtlich nich sind…
Gruß
Kalk
Tach!
Auf jeden Fall ists flasch, zu behaupten, die Spalten wären in „"“ eingeschlossen, wenn sie es offensichtlich nich sind…
Nein, das ist kein Fehler, denn das Einschließen ist optional und nur nötig, wenn Datensatzbegrenzer (Zeilenumbrüche) oder die Feldtrenner (hier Semikolon) als Bestandteil eines Wertes vorkommt.
dedlfix.
Idee: Füg mal die Spaltenüberschriften der CSV Datei hinzu und probiers nochmal.
Vermutlich willst Du:
1;;"Test Eintrag, weiß";"weiß";"Tisch-Rund, weiß 04/01/001";0.5;0,55;1,1;49;;15;"L1";;;20;;;;;;
(Eine Zeile)
denn bei Deinem scheinbar falschen:
"1;;Test Eintrag, weiß;weiß;Tisch-Rund, weiß 04/01/001;0,5;0,55;1,1;49;;15;L1;;;20;;;;;;"
wird versucht, alles (durch die umschließenden Quotas als eine Spalte formuliert) in die erste Spalte einzutragen - und deren Datentyp ist vermutlich auf einen der Integer-Typen gesetzt. Ferner kann es noch fehlschlagen, wenn die erste Spalte ein autoindex und also unique ist. Die 1 ein zweites mal einzutragen geht da nicht, es sei denn Du erstetzt den Inhalt. Das hast Du aber nicht ausgewählt.
Es sei denn, Deine Tabelle hat nur eine Spalte für Text… in welche wirklich alles hinein soll.
Ferner ist ein Punkt der Dezimaltrenner und bitte überprüfe ob da Kommas sind, welche Spaltentrenner, also Semikolons sein sollten.
Kurz gesagt: Dein "CSV" ist bestenfalls verwirrend und der Computer zu doof um zu wissen was Du willst. Also macht er, was Du ihm aufträgst. Genauer: Er versucht es.
Erinnert mich daran, dass mir bei der ostzonalen NVA mal ein Uffz (um seinen Rang zu beweisen) befohlen hat: "Alles Gras rupfen!" Ich hab den Klee stehen lassen. Es war fast nur Klee…
Erinnert mich daran, dass mir bei der ostzonalen NVA mal ein Uffz
Zeit für: UvD bei der NVA 😉
Hi there,
mit Deiner Verwendung des "-Zeichens hast Du die Reihe eingeschlossen, nicht die Spalten.
"1;;xxxx;yyyy;zzz;25" ist keine gültige CSV-Reihe - entweder Du schließt alle Spalten in Hochkommata ein (je nach Importierschnittstelle kann man die manchmal bei Zahlen weglassen) oder keine. Auf keinen Fall aber kann man den Inhalt einer ganzen Reihe in Hochkommata einschliessen, so wie Du es getan hast.…
Hallo,
Auf keinen Fall aber kann man den Inhalt einer ganzen Reihe in Hochkommata einschliessen, so wie Du es getan hast.…
Dochdoch, wie dedlfix bereits mitteilte, kann das gar nicht der Fehler sein…
Gruß
Kalk
Tach!
Auf keinen Fall aber kann man den Inhalt einer ganzen Reihe in Hochkommata einschliessen, so wie Du es getan hast.…
Dochdoch, wie dedlfix bereits mitteilte, kann das gar nicht der Fehler sein…
Dass die gesamte Zeile eingeschlossen war, hatte ich nicht gesehen. Ansonsten steht es aber so im Standard, dass die Zellen nicht eingerahmt sein müssen, solange kein Feld- oder Zeilentrenner drin vorkommt.
dedlfix.
Hallo,
Dass die gesamte Zeile eingeschlossen war, hatte ich nicht gesehen.
Dass im gezeigten Dialog explizit Spalteneinrahmung angehakt ist, hast du dann vermutlich auch nicht gesehen…
Ansonsten steht es aber so im Standard, dass die Zellen nicht eingerahmt sein müssen, solange kein Feld- oder Zeilentrenner drin vorkommt.
Um den Standard, also den allgemeinen Fall gehts aber grad nicht, sondern um sein spezielles Problem.
Gruß
Kalk
Tach!
Dass die gesamte Zeile eingeschlossen war, hatte ich nicht gesehen.
Dass im gezeigten Dialog explizit Spalteneinrahmung angehakt ist, hast du dann vermutlich auch nicht gesehen…
Doch, das hab ich gesehen. Und das ist auch richtig so, denn wenn optional die Spalten eingerahmt sind, dann muss das mit dem Zeichen geschehen, das dort angegeben ist. Oder andersrum, dann muss dort das verwendete Zeichen konfiguriert sein. Das heißt nicht, dass das Einrahmen damit zur Pflicht geworden ist.
dedlfix.
Hi there,
Hallo,
Auf keinen Fall aber kann man den Inhalt einer ganzen Reihe in Hochkommata einschliessen, so wie Du es getan hast.…
Dochdoch, wie dedlfix bereits mitteilte, kann das gar nicht der Fehler sein…
Hm? Hat er nicht mitgeteilt, und ich vermute nichtsdestotrotz, daß das (unter anderem) der Grund ist, warum der Import nicht funktioniert. Versuch einmal eine CSV-Datei irgendwo einzulesen, wo jede Reihe (und nur die Reihe) in einen Begrenzer eingeschlossen ist...
Hallo,
hier mal zwei Screenshots. Vielleicht mache ich ja etwas beim exportieren falsch?
Dieses ist meine Datei
Wenn ich dann in Excel auf speichern klicke erhalte ich folgende Auswahl, welchen CSV sollte ich hier nehmen?
Warum der Umweg über CSV?
Warum der Umweg über CSV?
Weil ich keine Excel Datei in phpMyAdmin einspielen kann?
Warum der Umweg über CSV?
Weil ich keine Excel Datei in phpMyAdmin einspielen kann?
Warum Excel nicht gleich mit PHP auslesen? Auf ein Array, das wird serialisiert, von mir aus JSON, zum Webserver gesendet und dort per PHP in MySQL eingebaut. Das ist doch die einfachste Sache der Welt.
Das ist doch die einfachste Sache der Welt.
Für dich vielleicht ;)
Warum Excel nicht gleich mit PHP auslesen? Auf ein Array, das wird serialisiert, von mir aus JSON, zum Webserver gesendet und dort per PHP in MySQL eingebaut.
Ich muss schauen wie ich mit PHP eine Excel Datei einlesen kann. Ist dieses wirklich besser als eine CSV Datei zu erzeugen?
Natürlich ist das besser: So weißt Du weningstens was Du tust.
Ich muss schauen wie ich mit PHP eine Excel Datei einlesen kann. Ist dieses wirklich besser als eine CSV Datei zu erzeugen? Natürlich ist das besser: So weißt Du wenigstens was Du tust.
Da bin ich mir nicht so sicher. Gründe:
Die Entwickler entsprechender Libs für den Import/Export von Excel-Dateien geben geradezu regelmäßig auf. 
Im Gegensatz zu CSV, welches in vergleichbar gut definierter Form nur die Daten eines "Tabellenblattes" (was schon von einer "Tabelle" zu unterscheiden ist) enthält, enthalten die Excel-Dateien mehrere Tabellenblätter. Und jede Menge Zeug (Formeln, Formatierungen) welches nachfolgend gar nicht in die Datenbank soll. Ich denke, mit dem Export und Import von CSV weiß man genauer, was man tut.
Microsoft kennt die Internas seines Stuffs und liefert mit Excel zusammen einen Exporter, der recht ordentlich funktioniert. Man kann sich das Resultat auch noch mit einem Text-Editor ansehen und sogar in Excel öffnen um es nicht nur zu bestaunen, sondern auch zu prüfen, ob es den Erwartungen entspricht.
Just das CSV-Zeug, welches mit Microsofts CSV-Export exportiert wird, lässt sich sehr zuverlässig in MySQL importieren. Die Voreinstellungen des Imports via PhpMyAdmin entsprechen, soweit ich das noch weiß, denen des Exports aus Excel. Das ist also auch noch bequem.
Freilich doch, wer gerne klickt darf das selbstverständlich auch weiterhin tun.
Die Entwickler entsprechender Libs für den Import/Export von Excel-Dateien geben geradezu regelmäßig auf.
Wer aufgibt hat die Bezeichnung Entwickler ganz sicher nicht verdient. Der sollte besser beim Klicken bleiben!
Wer aufgibt hat die Bezeichnung Entwickler ganz sicher nicht verdient.
Soso. Weißt Du, wie aufwendig und teuer es werden kann bei jeder Veränderung von Excel und PHP eine derartig komplizierte lib an das undokumentierte Zeug von Microsoft anzupassen? Die haben nicht umsonst ausgerechnet 2015 aufgegeben…
Außerdem hilft das dem TO nicht weiter, wenn Du ihn erst auf diesen Pfad führst und ihn dann mit diesem Spruch stehen lässt.
Freilich doch, wer gerne klickt darf das selbstverständlich auch weiterhin tun.
Ja toll. Der Umstieg auf eine alternative lib ist aber keine Lösung. Grund: Gerade solche Sachen sollen jahrelang funktionieren und der Austausch der lib ist kein Kinderspiel, sondern faktisch ein "Neuschrieb" mit allen Folgen: Tests, Tests, Tests.
Da ist es wesentlich besser bei dem vergleichbar primitiven Datenformat csv zu bleiben. Jedenfalls bis M$ einen JSON-Export bringt...
Warum sollte ausgerechnet JSON eine Lösung sein? application/json definiert einen Algorithmus aber nicht eine bestimmte Datenstrukur! So kann ein JSON String ein Array transportieren oder aber auch ein Array of Arrays. Oder auch assoziative Arrays, Strings und alles zusammen beliebig geschachtelt.
Da muss man schon ein bischen mehr vereinbaren wenn es darum geht komplexe Datenstrukturen portable zu machen application/json allein reicht da nicht.
Genausowenig wie text/csv reicht wenn keine Feldnamen drinstehen.
Da muss man schon ein bischen mehr vereinbaren wenn es darum geht komplexe Datenstrukturen portable zu machen application/json allein reicht da nicht.
Das ist bei CSV ebenso. Nur muss man da auch noch mindestens Kodierung, Zeilen- und Feldtrenner, Stringbegrenzer und Maskierungszeichen für denselben, eventuell noch das Auslassen der n ersten Zeilen vereinbaren (Falls da Kommentare oder, wie von Dir genannt, die Feldnamen drin stehen.)
Das ist bei json schon mal nicht nötig (UTF-8 ist default). Ein "Array of Hashes" (um bei der „perligen“ Nomenklatur zu bleiben) genügt für den Ex- und Import von Daten in und aus zweidimensionalen Datentabellen (oder zweidimensional "abgebildeten" Datenräumen).
Freilich kann man hingehen und eine Datenstruktur vereinbaren, mit der man das komplette Anlegen der Datenbank, der Tabellen und die Daten selbst beschreiben kann...
Ein "Array of Hashes" (um bei der „perligen“ Nomenklatur zu bleiben) genügt für den Ex- und Import von Daten in und aus zweidimensionalen Datentabellen (oder zweidimensional "abgebildeten" Datenräumen).
Dieser abstrakte Datentype hat den Nachteil, daß die Feldnamen redundant sind. Und was machst Du, wenn eine andere Kodierung vorliegt als utf8? Da ist Dein Vorschlag JSON nämlich Essig.
Idealerweise macht man sich beim Transport unabhängig von der Zeichenkodierung. Genausowenig kann man festlegen, daß JSON generell eine gute Idee sei, Daten zu übertragen.
MfG
Ein "Array of Hashes" (um bei der „perligen“ Nomenklatur zu bleiben) genügt für den Ex- und Import von Daten in und aus zweidimensionalen Datentabellen (oder zweidimensional "abgebildeten" Datenräumen).
Dieser abstrakte Datentype hat den Nachteil, daß die Feldnamen redundant sind.
Und was machst Du, wenn eine andere Kodierung vorliegt als utf8?
Idealerweise macht man sich beim Transport unabhängig von der Zeichenkodierung.
<?php
if ( FALSE === in_array( 'Transport', [ 'Export', 'Import' ] ) ) {
echo "Darum geht es hier nicht!" . PHP_EOL;
}
Darum geht es hier nicht!
Ein Lied für den UvD: "Wenn der Topf aber nun ein Loch hat..."
Aloha ;)
Ich muss schauen wie ich mit PHP eine Excel Datei einlesen kann. Ist dieses wirklich besser als eine CSV Datei zu erzeugen?
Unter der Voraussetzung, dass die Empfehlung a) von pl kommt und b) dir spanisch vorkommt, dann besteht eine über 90%ige Wahrscheinlichkeit, dass sie Murks ist.
Ich spreche aus Erfahrung.
Was nicht heißen soll, dass pl nur Murks erzählt. Was aber heißen soll, dass das, was sich bei ihm wie Murks anhört, auch Murks ist.
Grüße,
RIDER
Hallo pl,
Warum Excel nicht gleich mit PHP auslesen?
Um Excel-Dateien direkt zu lesen braucht man eins von folgendem
Nr. 1 wäre ggf. plattformportabel, Nr. 2 ist vermulich und Nr. 3 definitiv nur unter Windows verfügbar.
Für alles muss man einiges programmieren.
Wenn CSV Probleme macht, wäre ggf. noch das ODS-Format möglich. Excel kann das speichern, und phpMyAdmin kann das lesen.
Rolf
Um Excel-Dateien direkt zu lesen braucht man eins von folgendem
Nein, keins von dem. Was man braucht ist eine Library die zuverlässig funktioniert. So muß man überhaupt gar nicht das Dateiformat kennen sondern nur den Dateinamen, das Arbeitsblatt und den Bereich.
Z.B. eine Library wie Win32::OLE die es schon seit Ewigkleiten gibt.
MfG
Das ist doch jetzt hoffentlich nicht Dein Ernst, dass der TO sich unter Windows Perl, dazu Win32::OLE installiert um sodann mit einem selbst zu schreibenden Perl-Script Excel fernzusteuern, als dass dieser auf ungeheuer komplizierte, absurd langsame und geradezu unendlich fehlerträchtige Weise die Tabelle atomar (Zelle für Zelle) selbst ausliest - während Excel (sogar per Makro) selbst "gut durchdefinierte" CSV-Dateien liefern kann?
Das war ja auch nicht die Frage!
Tach!
Wenn ich dann in Excel auf speichern klicke erhalte ich folgende Auswahl, welchen CSV sollte ich hier nehmen?
Das erste. Zur Not auch das zweite. Wenn du allerdings ein Ergebnis bekommst, bei dem die komplette Zeile in Anführungszeichen steht, dann machst du was falsch. An Excel wird es nicht liegen, das wäre schon als großes Desaster aufgefallen.
dedlfix.
Hallo,
ok, habe ich so gemacht. Wenn ich jetzt den Import starte erhalte ich folgende Meldung
Ungültige Anzahl an Spalten im CSV-Import in Zeile 1.
Ich bekomme die Datei einfach nicht importiert. Keine Ahnung was ich noch machen soll. Jetzt sieht der Export so aus
ai_id;ai_code;ai_artikelid;ai_titel;ai_farbe;ai_beschreibung;ai_b;ai_t;ai_h;ai_preis;ai_status;ai_gewicht;ai_lagerplatz;ai_titelzusatz;ai_kategorie;ai_anzahl;;;;;;
;1;;Test 1;weiß;Test , weiß 04/01/001;0,5;0,55;1,1;49;;15;D1;;;20;;;;;;
;2;;Test 2;weiß;Test, weiß 04/01/002;0,5;0,5;1,1;49;;38;D1;;;16;;;;;;
(~~~ eingefügt von Rolf B, Leerzeile nach Spaltenüberschriften eingefügt vom Forum)
Die ai_id wird von der Datenbank selbst hochgezählt.
Tach!
Ungültige Anzahl an Spalten im CSV-Import in Zeile 1.
Ich bekomme die Datei einfach nicht importiert.
Interessanter wäre die Information gewesen, ob die Anzahl der Spalten in der CSV mit der Tabelle übereinstimmt oder nicht.
Keine Ahnung was ich noch machen soll.
Du kannst ja erstmal einen Import im Kleinen probieren. Eine Testtabelle mit übersichtlichen drei Spalten anlegen und eine Excel mit ebensoviel verwendeten Spalten nach CSV exportieren, und schauen ob das geht.
dedlfix.
Hallo,
Interessanter wäre die Information gewesen, ob die Anzahl der Spalten in der CSV mit der Tabelle übereinstimmt oder nicht.
die Spalten sind exakt die, die ich auch in der Datenbank habe.
Du kannst ja erstmal einen Import im Kleinen probieren. Eine Testtabelle mit übersichtlichen drei Spalten anlegen und eine Excel mit ebensoviel verwendeten Spalten nach CSV exportieren, und schauen ob das geht.
Ich habe eine Test Datei mit zwei Artikel angelegt und wollte diese importieren. Funktioniert leider nicht.
Tach!
Ich habe eine Test Datei mit zwei Artikel angelegt und wollte diese importieren. Funktioniert leider nicht.
Bei "funktioniert nicht" kann ich dir ganz genau das Problem sagen: Es liegt an der Ursache.
Hab grad mit 3 Spalten probiert, eine davon Auto-Increment und in der CSV leer, und hatte kein Problem beim Importieren.
dedlfix.
Hallo,
Hab grad mit 3 Spalten probiert, eine davon Auto-Increment und in der CSV leer, und hatte kein Problem beim Importieren.
jetzt hat es bei mir auch geklappt. Bin wie folgt vorgegangen:
Warum ich über diesen Umweg gehen muss, keine Ahnung. Vielleicht weil ich irgendwann mal in der Originaldatei Spalten gelöscht und eingefügt habe.
Wenn ich jetzt den Import starte erhalte ich folgende Meldung
Ungültige Anzahl an Spalten im CSV-Import in Zeile 1.
Das nenn ich mal eine klare Fehlermeldung!
<?php
### Schnelles Skript für die Überprüfung:
$rowDelim = "\r\n";
$colDelim = ';';
$myRowEnd = "\n"; # Unix-Konsole: "\n" | Windows-Terminal: "\r\n" | Browser "<br>";
$rows = file_get_contents('Excel.csv');
$rows = explode($rowDelim, $rows);
$counter = 0;
foreach ( $rows as $row ) {
$arItems = explode( $colDelim, $row );
echo "Zeile " . ++$counter . ' hat ' . count( $arItems ) . ' Spalten.' . $myRowEnd;
}
Vergleiche das Ergebnis mit Deinen Erwartungen, die sich mit
SHOW CREATE TABLE tabelle\G
manifestieren bzw. korrigieren lassen.
CSV Trennzeichen getrennt oder Text (Da ist stets das TAB das Trennzeichen zwischen den Items) sollten das sein, was Du suchst.
"Macintosh" und "MS-DOS" betreffen nur das Zeilenende ("\r" oder "\r\n").
Bleibt die Frage, ob "Unicode-Text" ideal ist. Was soll denn in der Datenbank landen? Wie ist die Tabelle angelegt?
SHOW CREATE TABLE `tabelle`\G
gibt Dir umfassend Auskunft
Hallo,
Da ist stets das TAB das Trennzeichen zwischen den Items
sicher?
Gruß
Kalk
Da ist stets das TAB das Trennzeichen zwischen den Items
sicher?
Na jedenfalls beschreibt Microsoft das so für das Export-Format "Text". CSV ist explizit aufgeführt.
sicher?
Nach dem Oktober-Update waren längst nicht nur Tabs, Kommas und Semikolons weg. Wie sollte man sich da bei Microsoft auch nur in irgendeiner Frage sicher sein?