Die Daten in der incons.csv sind komplett inkonsistent – zu Deutsch, zu einem Primärschlüssel gibt es unterschiedliche Werte => csvimporter sollte in allen außer der ersten Zeile eine Warnung ausgeben und die Zeile ignorieren.
Ja gut, äh… sicherlich…
Ich stelle einfach mal die These auf, dass die CSV-Dateien aus einer halbwegs konsistenten Datenbank exportiert worden sind. 
ok, dann passt das wohl wenn ich genau einen eintrag habe… danke
Hm… nach der Aufgabenstellung wohl eher nicht. Und wenn sie uns schon extra für fehlende Fehlerbehandlung Punktabzug androhen, würde ich eigentlich mal davon ausgehen, dass die durchaus auch auf sowas hinauswollen (wobei es wohl tatsächlich ausreichen könnte, einfach die Exceptions, die beim Insert auftauchen könnten, abzufangen…)
Ich hab gerade noch einen Fehler beim Testen von Kuenstler_Interpret behoben.
…und ein bisschen lästig wird die Escape-Geschichte ja langsam schon… Also wieder nicht escapen, statt dass man sagt, beide Lösungen sind ok… 
Ja, das find ich allerdings auch extrem schwach, vor allem weil in der “Spezifikation” mal wieder überhaupt nix davon drin steht. Eigentlich sollten die Daten so in der CSV Datei stehen, wie sie später auch in der Datenbank stehen sollen. Und wenn man das anders macht muss man das auch angeben.
Tja, laut Aufgabenstellung arbeitest du ja in einer “Firma”. Da gehörst du als Dipl.Informatiker dann ja auch hin, um CSV-Importeur zu werden. Und logisch, dass Spezifikationen in einer “Firma” grundsätzlich schlecht sind! Wärst halt an die Uni gegangen!
So wirds wohl sein Eine Firma die mir so eine “Spezifikation” geben würde, um dann jeden Tag zu kommen “Ach das hatten wir uns aber anders vorgestellt. Ne das wollen wir so!” würd ich als Softwareentwickler (der ich gar nicht sein will, aber egal) aber gleich wieder heimschicken.
Naja, ich hab jetzt jedenfalls eine Lösung zusammengezimmert, die eigentlich der “Spezifikation” genügen sollte. Auf den TableWriter hab ich ja wegen den netten vorescapten Strings doch verzichtet.
Seis drum. Letzte Aufgabe rum. Nie wieder SoS(2)!
Nagut, was haben wir denn für Fehlerquellen, die wir abfangen sollen:
- Die Parameteranzahl
- Die Anzahl der Attribute
- Fehlschlagen der Verbindung.
Ich bezweifle, das bei identischen Primary unterschiedliche andere Attribute vorhanden sind, die dann geupdatet werden müssen. Stellt euch mal vor, es wär’ so, dann wären ja die vorherigen Daten inkonsitent.
Die Daten wurden mit einem speziellen Programm exportiert, und sollen mit der Umkehrung wieder importiert werden.
Ich bau’ die ganze Zeit INSERTs und hab’ darum ein try…catch, somit verhindere ich, dass z.B. schon vorhanden Labels oder, was schneller zu identischen INSERTs führt, Regionen, eine Exception werfen.
Habt ihr noch zusätzliche Fehlerquellen ausgeschaltet?
Ciaoi