CSV-Kundenimport schlaegt fehl

[roman.karuschka@…]

Trotz mehrfacher Modifikationen und Eliminierung fast aller Spalten tauchen immer noch bei fast allen Datensaetzen Fehlermeldungen in folgender Form auf:

Fehler: insert into customer (street,zipcode,city,country,contact,phone,fax,email,customernumber,taxzone_id,import) values ('Seitenstr.1','12345','Badenbaden','Deutschland','Finanzplanung und Versicherungen',null,'1234/1234',null,'12345',0,1244130368)
Fehler: insert into customer (street,zipcode,city,country,contact,phone,fax,email,customernumber,taxzone_id,import) values

...

und so weiter...

Kurioserweise schaffen es beim Import der vollen CSV (ca 1100 Datensaetze) einige davon doch in die DB, aber es sind viele Verschobene dabei (z.B. Tel.-Nr als Name etc)

UTF8, CSV mit Semikolen oder Kommata getrennt. Kundennummern soll das System selbst vergeben, liegen in der CSV nicht vor.

Beim Testimport sieht alles noch gut aus, erst beim tatsaechlichen Import geht es wirklich schief und die Fehlermeldungen fliegen.

Auch eine streng nach Wiki gebaute Test-CSV mit den dort vorgeschlagenen Spalten bringt keine Besserung.

Also ich hätte gerne das Importfile gesehen.

"contact" ist dem Beispiel "Finanzplanung und Versicherungen"

Hallo,

ich mache morgen mal ein Exemplar fertig. Contact und Firmenname ist
uebrigens tatsaechlich bewusst vertauscht worden bei der LX-Office
einsetzenden Firma, da mit Dem Firmennamen/Namen? eine Anrede
verknuepfbar ist und die Kontakte immer Einzelpersonen gelten, mit den
Firmen wird an sich keine Geschaeftsbeziehung gepflegt (oder um es
deutlicher zu sagen, einige Kunden lassen sich ihre Auftraege mit der
zusaetzlichen Firmenangabe senden um die Rechnungen danach bei der
Steuer absetzen zu koennen, der wirkliche Kontakt gilt aber eben der
Einzelperson, die Firma ist nachrangig, und die Anrede ist wichtig, ein
Anredefeld gibt es aber fuer Contact nicht).
Somit sind die dort vertauschten Angaben kein Fehler ;-)

Aber zurueck zum Thema.
Der Aeusserung zufolge hat das Problem niemand ausser mir dort?
Betreibe zwei Systeme (auf zwei versch. Servern) mit unstable, eines
fuer den Kunden, eines zum Testen bevor ich ein Update beim Kunden
einspiele. Das Problem tritt tatsaechlich auf Beiden auf. In 2.4.3
wurden aehnliche Importdateien problemlos uebernommen (dafuer gab's andere Bugs von denen viele in 2.6 nicht mehr da sind, Ziel ist also moeglichst bald alles auf 2.6 zu stellen)

DB ist UTF8, LX steht auf UTF8, Importfile UTF8, erst dachte ich es laege evtl an den extrem langen notes-Feldern, aber auch nach deren Entfernung blieb das Problem.

wiie ist der Status dieses Bugs?

Holger ist gerade im Urlaub, Roman, hat sich da schon was getan?

Ich starte da kommende Woche nochmals einen neuen Anlauf drauf, so im Nachhinein, drueber nachgedacht, koennte es evtl ein Feldlaengenproblem sein, weil in den CSVs sehr lange Bemerkungsprotokolle stehen.

Ich gewichte das Ding mal herunter solang.

Hallo zusammen,
zumindestens die harte Kodierung der Einzelfelder nach ISO ist jetzt endlich gefixt.
Falls Holger noch möchte, sehe ich noch folgende Erweiterungen:

1.) Unter Hilfe (Beispielimport)
kommen (...);customernumber;vendornumber;(...) als Beispiel raus. Hier wäre es schön noch einen Fallunterschied für das jeweilige angehakte Beispiel zu haben (customer oder vendor), damit dann so copy&paste-Leute wie ich glücklicher sind.

2.) DB-Encoding herausfinden und entsprechend kodieren (Für Mandanten pre2.6).

3.) Ich prüfe die Kodierung derzeit für jeden Dateneintrag, besser wäre es hier einmal nur die Kodierung des Files herauszufinden.

4.) Österreich-Bug, lustigerweise werden Umlaute am Anfang des Datenfeldes abgeschnitten. Das wäre auch noch schön zu ändern.
Ähnliches Problem wie hier:

​http://forum.de.selfhtml.org/archiv/2007/1/t143904/

Für mich ist das prinzipielle Problem (geht gar nicht), aber erstmal behoben und übergeben dann an holger ...

@roman einfach wieder öffnen

@Jan

$encoding = mb_detect_encoding($data,"UTF-8,ISO-8859-1,ISO-8859-15");
Ist es überhaupt sinnvoll jede Zeile zu konvertieren? Jede Zeile abfragen nur um zu sehen ob da überhaupt etwas übersetzt werden muß. X-Stellen ändern usw.

Warum nicht den Client, in diesem Fall php, auf die Ausgangscodierung umstellen, also "latin-9"? Durch Umstellen von db.php auf mdb2.php ist das sehr einfach möglich:

$db = MDB2::factory($dsn,$option);
$db->setCharset('latin9');

oder per sql "SET CLIENT_ENCODING TO 'UNICODE' "

Dann sollten Server und Client das richtig aushandeln. Text mit dem Shopimport waren bisher erfolgreich.

Ein beherztes "show server_encoding;" zeigt dir die Servecodierung.

import Österreich

Hi Holger,
das automatische Erkennen von ISO oder UTF-8 ist i.O.
UST-ID wird auch korrekt ausgegeben.
Bei Österreich als Land wird aber immer noch das Ö abgeschnitten.
Anbei mein Testimport.csv