Ich habe einen Kategorienbaum mit einer Höhe > 1. Nun will ich per Import-Funktion Daten in die Kategorie Passiv | Widerstand | smd | 0805 importieren. Wie muss ich die Kategorie in der csv-Datei schreiben?
Hallo Uhu, Leider können in der CSV Datei keine verschachtelten Kategorien angegeben werden. Der Import funktioniert sehr primitiv, er sucht einfach nach Kategorien die den gleichen Namen wie die im CSV definierte Kategorie haben. Gibt es keine Kategorie mit diesem Namen, wird eine neue angelegt (mit "Import" als Elternkategorie). Gibt es eine oder mehrere Kategiren mit diesem Namen, wird einfach die erste davon genommen, deren Elternkategorien werden komplett ignoriert. Sofern du also nur eine Kategorie mit dem Namen "0805" hast, kannst du einfach "0805" im CSV angeben. Wenn aber mehrere Kategorien mit dem Namen "0805" vorhanden sind, müsstest du als Workaround (zumindest für dem Import) die Kategorien umbenennen, so dass der Name eindeutig ist (z.B. "R-0805" und "C-0805"). mfg Urban
Das ist sehr schade. Man spart zwar einiges an Schreibarbeit durch den Import, muss aber dann jeden Artikel nochmal anfassen um ihn in die richtige Kategorie zu bekommen. Wäre es denkbar, die Daten direkt in die DB zu bekommen?
Naja, jeden Artikel nochmal anfassen musst du eben nicht, der Import funktioniert ja einwandfrei wenn die Kategorien eindeutige Namen haben. Du musst also höchstens vor dem Import ein paar wenige Kategorien leicht umbenennen, danach geht alles vollautomatisch. Ich denke damit kann man ganz gut leben, da es ja nur selten Kategorien mit gleichem Namen gibt. Falls deine gewünschten Kategorien noch nicht existieren und du dir erhoffst dass beim Import auch alle Kategorien inklusive Hierarchie angelegt werden: Das ist auch nicht soo tragisch, dann wird halt beim Import eine Kategorie mit dem Namen "Passiv | Widerstand | smd | 0805" (ohne Hierarchie) in der Unterkategorie "Import" angelegt und alle entsprechenden Bauteile dieser Kategorie zugeordnet. Dann musst du halt nach dem Import noch die Kategorien "Passiv" -> "Widerstand" -> "smd" erstellen (inkl. Hierarchie) und die vom Importer angelegte Kategorie in "0805" umbenennen und als Elternkategorie "smd" zuweisen. Alle Bauteile von "0805" bleiben weiterhin dort drin, du brauchst die Bauteile nicht auch noch anzupassen. Die Daten direkt in die DB importieren geht theoretisch auch, allerdings hast du dann keinerlei Überprüfung ob die Daten auch für Part-DB gültig sind, das könnte zu weiteren Problemen führen. Und ob das einfacher ist als die oben genannte Variante bezweifle ich (musst selbst ein Import Script schreiben)...
:
Bearbeitet durch User
OK, das mit dem flache Kategorie in geschachtelte umbenennen, ist eine Lösung. Danke für den Tipp.
Jetzt habe ich einen Schwung Teile erfasst und er liest sie auch ein. Die Liste mit den Daten sieht gut aus - nur übernimmt er nicht einen einzigen Artikel. Footprints und Kategorien existieren. Die Spalten Beschreibung, Kommentar, Hersteller, Lieferant und Bestellnummer sind leer. Der Preis ist überall 0. Liegt das evtl. daran?
:
Bearbeitet durch User
Das ist merkwürdig... Die leeren Spalten sollten jedenfalls eigentlich kein Problem darstellen. Kommt keinerlei Fehlermeldung? Welche Part-DB Version verwendest du (Release oder git)?
Ich habe Version: 0.3.1 (stable) in einer VM von VirtualBox unter Linux Mint 17 laufen. Es kommt überhaupt keine Meldung beim Übernehmen der Daten, lediglich die Liste mit den den Spalten zugeordneten Daten verschwindet. Die .csv-Datei wird noch angezeigt.
Angehängte Dateien:
-
Part-DB_Import.png
22 KB
Also ich habs mal mit dem Beispiel-CSV ausprobiert, das funktioniert einwandfrei: https://raw.githubusercontent.com/sandboxgangster/Part-DB/master/development/testfiles/import_parts/csv_correct.csv Du hast schon gesehen dass man nach dem Übernehmen der Daten noch auf einen weiteren Button "Daten importieren!" (siehe Bild) klicken muss, oder? :) Oder erscheint dieser Button bei dir gar nicht erst? Evtl. liegts ja aber auch an deinem CSV. Wenn du willst kannst du mir die Datei schicken, dann schaue ich mir das mal an. Ansonsten bräuchte ich eine genauere Fehlerbeschreibung (welche Buttons klickst du in welcher Reihenfolge und wann kommt welcher Output)...
:
Bearbeitet durch User
Angehängte Dateien:
-
Screenshot.png
32 KB
Der Daten Importieren - Button fehlt hier. Ich hab dir eine PN mit dem Dropbox-Link geschickt.
Ok ich konnte das Problem reproduzieren und beheben. Und zwar wird beim Import schnell mal das PHP Limit "max_input_vars" überschritten, wodurch Part-DB ein unvollständiges array zurückgeliefert bekommt und nicht mehr richtig funktioniert. Die Lösung ist also in der PHP Konfiguration (z.B. /etc/php5/apache2/php.ini) den Wert von "max_input_vars" zu erhöhen, z.B. auf 10'000 (Standard ist 1'000). Ich mach auf unserer Github Projektseite grad noch ein Issue auf zu diesem Thema...
Ach ja, anstatt die globale PHP Konfiguration zu ändern, kann man natürlich auch die .htaccess anpassen... Hier übrigens noch das neue Issue: https://github.com/sandboxgangster/Part-DB/issues/47
Ich frage mich, wozu eigentlich alle Felder in Edits angezeigt werden müssen. .csv-Daten kann man mit jeder Tabellenkalkulation inspizieren und für das xml-Format müsste es doch auch die Möglichkeit geben, die Daten außerhalb part-db zu inspizieren und zu konnigieren. Dann könnte man die Editiererei aus part-db einfach rausschmeißen und das Problem ist aus der Welt.
Das ist natürlich auch eine Möglichkeit. Allerdings ist es halt schon angenehm wenn man direkt in Part-DB gewisse Angaben korrigieren kann. Insbesondere für XML kenne ich kein eigenständiges Tool um das gescheit machen zu können. Immerhin gibt es ja einen Workaround um trotzdem grössere Dateien importieren zu können. Wie das Problem behoben werden soll, kann jetzt auf Github diskutiert werden (bitte nicht hier).
Urban B. schrieb: > Immerhin gibt es ja einen Workaround um trotzdem grössere Dateien > importieren zu können. Wie das Problem behoben werden soll, kann jetzt > auf Github diskutiert werden (bitte nicht hier). Das ist halt eine ewige Fehlerquelle, zumal man überhaupt keine Hinweise auf die Ursache bekommt. Woher kommen denn diese xml-Dateien?
Nochmal zurück zum Ausgangsproblem: geschachtelte Kategorien. Bei mir gibt es bereits eine nichtleere Kategorie _0805. Nun habe ich weitere Teile in eine neue Kategorie R0805 importiert. Wenn ich diese Kategorie nach _0805 umbenennen will, dann mault er - zurecht -, die _0805 gäbe es bereits. Der Trick mit dem Kategorie umbenennen geht also leider nur, wenn die Zielkategorie noch nicht existiert...
Uhu U. schrieb: > Der Trick mit dem Kategorie umbenennen geht also leider nur, wenn die > Zielkategorie noch nicht existiert... Das ist richtig. Wenn die Zielkategorie schon existiert, müssen die Teile einfach direkt in diese Kategorie importiert werden, also in deinem Fall "_0805".
:
Bearbeitet durch User
Urban B. schrieb: > Ach ja, anstatt die globale PHP Konfiguration zu ändern, kann man > natürlich auch die .htaccess anpassen... > > Hier übrigens noch das neue Issue: > https://github.com/sandboxgangster/Part-DB/issues/47 Das Problem mit den "max_input_vars" könnte man eventuell beheben, wenn man das Formular in der Tabelle sinnvoller aufbaut. So wie ich das interpretiere, erzeugt das eine Unmenge an Input-Feldern mit fortlaufend numerierten Namen: <pre> <input type="text" style="width:45px" name="instock_{TMPL_VAR NAME="row_index"}" value="{TMPL_VAR NAME="instock"}" onkeypress="validatePosIntNumber(event)"></td> </pre> Das erzeugt halt Input-Felder mit Namen wie "instock_0", "instock_1", "instock_2" und so weiter. Man sollte da besser ein Array draus machen, das zählt dann nämlich als eine einzige Variable. Die Input-Felder müssten dann entweder alle "instock[]" heißen oder numeriert sein, etwa "instock[0]", "instock[1]" und so weiter.
Dein Ansatz hat leider eine andere Falle, nämlich der Datenmenge selbst. Besser ist es, den Import vorher in eine temporäre Tabelle zu machen und von dort aus die Bauteile in den Bestand zu übernehmen. Hier wird nur noch der Index benötigt, was vieles vereinfacht. Ich werde mich da mal dran machen, kann aber etwas dauern.
Udo N. schrieb: > Dein Ansatz hat leider eine andere Falle, nämlich der Datenmenge selbst. Diese Falle ist aber arbiträr. Bei phpMyAdmin und wie sie alle heißen, hast du das ja auch. max_input_vars hat seine Ursache angeblich in den PHP-internen Hashtabellen, glaubt man der Doku[1]. Die Datenmenge an sich ist eine Frage, was man denn können will. Die Grenze kann man problem- und weitgehend risikolos anheben. Bei max_input_vars hingegen hat man eher ein Designproblem... [1]: http://php.net/manual/de/info.configuration.php#ini.max-input-vars
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.