Excel-Datei mit Zeilenumbruch - Import bricht ab

Hallo,

bekomme heute von einem Bekannten eine Kundendatei im XLS-Format, um mit ihr eine Datenbank aufzubauen.

Das würde auch auch alles gut funktionieren, wenn nicht die Telefoneinträge durch einen Zeilenumbruch innerhalb einer Zelle (bei mehreren Telefonnummern - erzeugt mit ALT-ENTER) voneinander getrennt wären.

PGADMIn interpretiert das als neue Zeile und bricht den Import ab.

In Excel den Zeilenumbruch nachträglich herausnehmen klappt nicht, es bleibt trotzdem ein Steuerzeichen übrig.

Habt Ihr eine Idee, wie ich das am schnellsten löse?


Gruß aus Scheeßel

Bernd

Ich sehe bis jetzt kein Problem.

PGADMIn interpretiert das als neue Zeile und bricht den Import ab.

Ahhh, jetzt. Und warum nimmst Du PGAdmin?

In Excel den Zeilenumbruch nachträglich herausnehmen klappt nicht, es bleibt trotzdem ein Steuerzeichen übrig.

Habt Ihr eine Idee, wie ich das am schnellsten löse?

Exportiere das im Excell als CSV und nutze COPY.

test=# create table foo (id int, t text);
CREATE TABLE
test=*# commit;
COMMIT
test=# insert into foo values (1, 'das
test'# ist
test'# ein
test'# test');
INSERT 0 1
test=*# commit;
COMMIT
test=# select * from foo;
 id |        t
----+------------------
  1 | das
ist
ein
test
(1 row)

test=*# commit;
COMMIT
test=# copy foo to stdout;
1       das\nist\nein\ntest
test=*# copy foo to '/tmp/foo.txt';
COPY
test=*# copy foo to stdout csv;
1,"das
ist
ein
test"
test=*# copy foo to '/tmp/foo.txt' csv;
COPY
test=*#

Die entstandenen Dateien schauen so aus:

kretschmer@pegasus:~$ cat /tmp/foo.txt
1       das\nist\nein\ntest
kretschmer@pegasus:~$ cat /tmp/foo.txt
1,"das
ist
ein
test"
kretschmer@pegasus:~$

Andreas

Hallo,

werde ich gleich versuchen, dankeschön :slight_smile:

Copy hatte ich ja benutzt…nur eben auf PGADMIN-Oberfläche

Gruß Bernd

Das macht vermutlich auch dasselbe - irgendwie. Man muß halt schauen, was Excel so ausgibt, und dafür die passenden Optionen finden und/oder mit Texttools (awk, sed, …) vorher noch nachbessern.

Andreas

Hallo,

öfter mal was Neues :slight_smile:

Jetzt bricht der Import der CSV-Datei mit folgender Fehlermeldung ab:
*extra data after last expected column
*

Hinter der letzten Zeile sind keinerlei Daten; auch keine Leerzeilen.

Wie kann es zu der Fehlermeldung kommen?

PS: arbeite unter Windows XP

Ein schönes Wochenende

wünscht

Bernd :slight_smile:

row != column

Wie kann es zu der Fehlermeldung kommen?

Wenn die Tabelle N Spalten hat, die CSV-Datei aber N+X mit X > 0 Spalten hat.

PS: arbeite unter Windows XP

Meine Beileidsbekundungen dafür sind zu Ende…


Andreas

Ja, das kommt bei mir auch:

FEHLER: zusätzliche Daten nach letzter erwarteter Spalte
CONTEXT: COPY testtabelle2, Zeile 1: »DasIstEinTeststrin20:>==================>:«
SQL state: 22P04
Dies ist eine Testdatei mit 2 charakter-feldern mit je 20 Zeichen, Delimiter “:”

Wenn ich die Datei im oowriter ansehe und die Steuerzeichen sichbar mache, sieht man dieses verkehrte “P”, was vermutlich “Carriage return” bedeutet.

Die Datei ist im Linux (Informix aus dem Jahre 1989, aus XENIX portiert, mit ABI/ibcs ) entstanden und im Postgres im Linux mit dem Befehl COPY bearbeitet worden.

Mein Problem ist eben, diese alten Daten in eine moderne Datenbank zu bekommen.

Gibt es eine Möglichkeit, diese Steuerzeichen wegzubekommen?

Ich erinnere mich, einmal so ein Problem mit dem Befehl awk gelöst zu haben. Da ging es um das Einlesen von Daten aus einer Textdatei in dieses alte Informix. Muss sehen, ob ich den Quelltext noch finde. Vielleicht hilft der uns beid em Problem.

Liegt das am Forum-Software-Update, oder an der Scheiß-Kälte draußen, daß jetzt vermehrt überlagerte Threads wieder hochkommen?


FEHLER: zusätzliche Daten nach letzter erwarteter Spalte
CONTEXT: COPY testtabelle2, Zeile 1: »DasIstEinTeststrin20:>==================>:«
SQL state: 22P04
Dies ist eine Testdatei mit 2 charakter-feldern mit je 20 Zeichen, Delimiter “:”

Wenn ich die Datei im oowriter ansehe und die Steuerzeichen sichbar mache, sieht man dieses verkehrte “P”, was vermutlich “Carriage return” bedeutet.

Oh mann. OOo-Dingens als M$-Office-Ersatz für arme Leute. Man schaut sich keine Text-ASCII-Datei mit solch einem Monster an, weder unter Windoze noch unter *NIX.
Während das noch öffnet, sehen Benutzer passender Tools schon alles, was erstere nie zu sehen bekommen …

Die Datei ist im Linux (Informix aus dem Jahre 1989, aus XENIX portiert, mit ABI/ibcs ) entstanden und im Postgres im Linux mit dem Befehl COPY bearbeitet worden.

Mein Problem ist eben, diese alten Daten in eine moderne Datenbank zu bekommen.

Gibt es eine Möglichkeit, diese Steuerzeichen wegzubekommen?

Ich erinnere mich, einmal so ein Problem mit dem Befehl awk gelöst zu haben. Da ging es um das Einlesen von Daten aus einer Textdatei in dieses alte Informix. Muss sehen, ob ich den Quelltext noch finde. Vielleicht hilft der uns beid em Problem.

Ja, Tools wie awk sind in der Tat das Mittel der Wahl für sowas.

Allgemein: Zeichensatz-Konverter › Wiki › ubuntuusers.de

(ich vermute, Du hast ein Linux)

Andreas

Oh mann. OOo-Dingens als M$-Office-Ersatz für arme Leute. Man schaut sich keine Text-ASCII-Datei mit solch einem Monster an, weder unter Windoze noch unter *NIX.
Während das noch öffnet, sehen Benutzer passender Tools schon alles, was erstere nie zu sehen bekommen …

mit vim kann ich die Steurzeichen nicht sehen. Und mein kleiner HP-mini ist doch schnell genug für oowriter :slight_smile:



Hab’ den awk-Befehl gefunden, mit dem mein Programm den Fehler beim Einlesen einer Wartungsdatei (Zusatztext zu einem Medikament) monatlich löst:

awk ‘BEGIN {RS="\r"} {printf("%s\n",$0)}’ tab.txt > tab.corr

Aber mein aktuelles Problem konnte ich so nicht lösen.

Das Steuerzeichen kann nicht der Grund für den Fehler sein.


Denn durch Löschen des letzte Delimiters (Am Ende der letzten Spalt) konnten die Testdaten korrekt geladen werden.
Bei den Echt-Daten ist es mir noch nicht gelungen. Auch wenn ich den Doppelpunkt am Ende der letzten Spalte lösche, kommt der Fehler.