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.
Ahhh, jetzt. Und warum nimmst Du PGAdmin?PGADMIn interpretiert das als neue Zeile und bricht den Import ab.
Exportiere das im Excell als CSV und nutze COPY.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?
Die entstandenen Dateien schauen so aus:Code: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=*#
Code: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
--
PostgreSQL Hosting
http://www.amazon.de/gp/registry/2APKFICAIYMWBads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
https://www.xing.com/profile/Andreas_Kretschmer7
Hallo,
werde ich gleich versuchen, dankeschön
Copy hatte ich ja benutzt...nur eben auf PGADMIN-Oberfläche
Gruß Bernd
--
PostgreSQL Hosting
http://www.amazon.de/gp/registry/2APKFICAIYMWBads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
https://www.xing.com/profile/Andreas_Kretschmer7
Hallo,
öfter mal was Neues
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![]()
--
PostgreSQL Hosting
http://www.amazon.de/gp/registry/2APKFICAIYMWBads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
https://www.xing.com/profile/Andreas_Kretschmer7
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?
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.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.
Während das noch öffnet, sehen Benutzer passender Tools schon alles, was erstere nie zu sehen bekommen ...
Ja, Tools wie awk sind in der Tat das Mittel der Wahl für sowas.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.
Allgemein: Zeichensatz-Konverter › Wiki › ubuntuusers.de
(ich vermute, Du hast ein Linux)
Andreas
--
PostgreSQL Hosting
http://www.amazon.de/gp/registry/2APKFICAIYMWBads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
https://www.xing.com/profile/Andreas_Kretschmer7
mit vim kann ich die Steurzeichen nicht sehen. Und mein kleiner HP-mini ist doch schnell genug für oowriter :-)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 ...
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.
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen