dbf nach PostgreSQL konvertieren

Moin zusammen,

als Newbie -sorry schon mal- stehe ich vor der Herausforderung, 5 -in Worten fünf- dbf-Dateien in PostgreSQL konvertieren zu wollen.
Ich arbeite über Windows XP, neueste Version PostgreSQl 8.3.5.

wiki.postgresql.org/wiki/Converting_from_other_Databases_to_PostgreSQL habe ich bereits durchgeackert:

DBase II, III, IV+ Convert .dbf files into PostgreSQL by Tomasz Judycki
habe ich versucht, damit bin ich überfordert.

ESF Database Convert - 5.9.44 Das habe ich zum Laufen bekommen. Es ist grandios für den normalen Gebrauch nicht zu verwenden: Note: It is an evaluation version. It will replace the first charcter to ‘T’ for every TEXT value. DAS IST SO!

dbf2pg habe ich nach Schwierigkeiten zwar gefunden, komme damit aber überhaupt nicht klar.

Das, was ich zum Laufen bekommen habe und was mir vom Handling her liegt, ist: “Data Import 2007 for PostgreSQL” von sqlmanager.
Damit komme ich gut zurecht, es importiert aber jeweils nur 20% der Datensätze!

Hat einer von euch ´ne Idee?

Kann man die alten Dateien aus dem Originalprogramm irgendwie im Textformat exportieren? Als CSV zum Beispiel?

Das würde die Sache ungemein vereinfachen.

Das wäre das kleinste Problem: dbf > in Excel einlesen > als csv speichern > fertig. Ich habe nur max. 60.000 Datensätze - das kann Excel noch. Und dann?

CSV zu importieren ist trivial - mit COPY.

Andreas

Das Problem ist: Excel kann nicht mehr als die 60k Zeilen (oder so was in dem Dreh) bearbeiten. Der Rest der Daten wäre dann weg.

Wie heißt man das denn?

Wenn agns.csv meine CSV-Datei sei, wie ist denn dann der Befehl?
COPY tbl_neubenamst FROM ‘/home/user/agnsv.csv’; ???
Wird eine neue Tabelle aufgemacht oder muss die vorher erstellt sein? Woher weiß PostgreSQL welche DB und wo die csv-Datei liegt? Ich stehe da auf dem Schlauch…

Also die Hilfe zu CSV ist schon sehr umfangreich:

PostgreSQL: Documentation: Manuals: PostgreSQL 8.3: COPY

Sorry, wie gesagt: Newbie. Ich werde mich da mal durchforsten und falls noch Fragen offen bleiben, mich melden. Ich hatte versucht, mit dem Peter Eisentraut; PostgreSQL: Das Offizielle Handbuch weiterzukommen. Das hat mir nicht gereicht. Deshalb: vielen Dank bis hierhin.

Hallo zusammen,

mittlerweile bin ich soweit, dass die zu kopierende csv-Datei tatsächlich gefunden wird. Mit den Fehlermeldungen komme ich aber nicht klar. Was nun?

kani=# COPY agns
        FROM E'D:\\agns.csv'
        WITH DELIMITER ';' CSV HEADER
        ;
ERROR:  invalid byte sequence for encoding "SJIS": 0x8e3b
HINT:  This error can also happen if the byte sequence does not match the encodi
ng expected by the server, which is controlled by "client_encoding".
CONTEXT:  COPY agns, line 25924

Ich habe die Zeile angesehen, da tauchen Umlaute auf. Aber in den darüberliegenden Zeilen waren auch bereits welche?!

Setze Dein client_encoding auf SJIS.

Andreas

Vor ein paar Tagen, warst Du der Meinung ich wäre schon Japaner.

Seit dem habe ich daran nichts geändert.

In der Reference finde ich:

Name Description Language Server? Bytes/Char Aliases
SJIS Shift JIS Japanese No 1-2 Mskanji, ShiftJIS, WIN932, Windows932

Server Character Set Available Client Character Sets
SJIS not supported as a server encoding :confused:
Kann es das wirklich sein?!

Offensichtlich ist das Encoding (wohl auf Serverseite) aber so gesetzt. Und die Daten, die die Clientseite sendet, passen da nicht rein.

Ich empfehle dir, im Online Handbuch mal zu Server Encoding und Client Encoding nachzulesen.

Um das noch einmal zu erklären:

meine DB läuft mit UTF8.

test=# set client_encoding='latin2';
SET
Zeit: 39,177 ms
test=*# insert into testdata (tabellenspalte1) values ('äöü');
INSERT 0 1
Zeit: 0,270 ms
test=*# rollback;
ROLLBACK
Zeit: 0,224 ms
test=# set client_encoding='latin3';
SET
Zeit: 0,193 ms
test=*# insert into testdata (tabellenspalte1) values ('äöü');
ERROR:  character 0xc3 of encoding "LATIN3" has no equivalent in "UTF8"
test=!# rollback;
ROLLBACK
Zeit: 0,130 ms
test=# set client_encoding='SJIS';
SET
Zeit: 0,087 ms
test=*# insert into testdata (tabellenspalte1) values ('äöü');
INSERT 0 1
Zeit: 0,243 ms
test=*#

Ich hab nun mal wild client_encoding gesetzt, und wie man sieht, gibt es Fälle, wo das dann bei identischen Daten, die ich einzugeben versuche, nicht funktioniert.

Meine Frage, ob Du Japaner bist, rührte daher, daß in einem Deiner Postings Du das SJIS als Encoding verwendet hast. Möglicherweise war Dir nicht klar, was das ist und welche Folgen das hat.

Summa summarum: das, was Du eingeben willst, muß sowohl durch die DB abbildbar sein als auch vom Client so kommen, daß es nötigenfalls in das Server-Encoding transformiert werden kann. Klappt das nicht, kommen die Dir bekannten Fehler.

Andreas

Für denjenigen, der viel Erfahrung hat, nerve ich vielleicht. Mein Problem ist offensichtlich zu trivial, aber für meine Verhältnisse habe ich mich hier in Welten vorgewagt, die ich vorher noch nie betreten habe (oder musste) und gehöre nicht zur Trivialitätsentität. Deshalb bitte ich um etwas Rücksicht und tatsächliche Hilfe. Würde ich die Reference auswendig kennen, müsste ich hier nicht fragen.

Außerdem bin ich mittlerweile mit den Nerven zu Fuß und kann nicht noch Tage diesem Problem hinterherlaufen.

Mein jetziger Stand:

kani=# show server_encoding;
server_encoding
-----------------
UTF8                    ---Server encoding also auf UTF8
(1 row)

kani-# \encoding        ---ist das nicht das Client encoding? dann wäre das doch auf SJIS
SJIS

Ist jemand willens mir zu helfen und mir kurz mal in Befehlen aufschreiben, wie ich dieses Problem schnell löse?

Sorry Andreas, ich wollte dich nicht anpaulen. Da sind unser posts wohl über Kreuz gelaufen. Und wenn man noch nicht einmal die Steine sieht auf die man springen soll…

Hier noch etwas Neues: Ich habe die csv-Datei von allen Umlauten gereinigt (!) und erhalte trotzdem:

kani=# COPY agns
        FROM E'D:\\agns II.csv'
        WITH DELIMITER ';' CSV HEADER
        ;
ERROR:  invalid byte sequence for encoding "SJIS": 0xe13b
HINT:  This error can also happen if the byte sequence does not match the encodi
ng expected by the server, which is controlled by "client_encoding".
CONTEXT:  COPY agns, line 40688

Hallo Alfredo,

ich hatte das Problem bisher noch nicht, aber was mir einfällt:

Was passiert wenn du direkt vor dem copy-befehl das client-encoding setzt?:
Ich hab nur leider keine Ahnung wie das Encoding unter Windows normalerweise aussieht, vielleicht

SET CLIENT_ENCODING='WIN1252';

als SQL-Befehl direkt vor dem copy.

Wo genau kommt die Datei denn her? Wenn die unter einem anderen Betriebssystem erstellt wurde könnte auch das das Problem sein.


Gruß
der Sparrow

Und wo kommt das SJIS her?
Dein Client ist auf japanisch eingestellt, das muss schon eine Ursache haben.

Wäre vielleicht für die Lösung des Problems praktisch, wenn du herausfindest wie das passiert. Danach löst sich wahrscheinlich dein anderes Problem auch mit auf.

Hallo Sparrow,
Deinen Tipp probier ich morgen aus und werde berichten. Bin etwas fertig heute, deshalb schwächle ich.
Die Dateien sind immer auf Windows gelaufen . Es sind 5 relational verknüpfte dBase-Dateien aus einer selbstgestrickten Datenbank inkl. Graphical Frontend (nicht von mir). Es werden von mir nach wie vor Daten eingegeben, die Datenqualität ist unterirdisch, es läuft auf einem Windows 98 Rechner und stürzt dauernd ab. Deshalb hege ich den dringenden Wunsch, dieses alte Programm mit der DB zu erneuern und endlich etwas vernünftiges davon zu machen. Der Export funktioniert über eine mit arj gestuffte Datei, die dann die 5 dBase-Dateien enthält.

Bei der Installation von PostgreSQL, die ich vollständig und das erste Mal vor mittlerweile ganzen 4 Tagen bewerkstelligt habe, habe ich im Fenster “Datenbank-Cluster initialisieren” bei Encoding … und Client… nur eine Kombination gefunden, die überhaupt funktionierte. Das war dummerweise UTF8 und SJIS. Mit LATIN1 funktionierte bei Client gar nichts.
Mir ist vollkommen egal warum! Für mich ist das “was-nun?” viel wichtiger. Also was schlägst du vor? Welche Kombination soll ich wie einstellen?

Grüße
Carsten

Latin1, UTF8, Win-*irgendwas, aber kein Japanisch.
Damit holst du dir mehr Probleme als du löst.

Moin moin,

das Problem mit dem encoding scheint gelöst zu sein. Es funktioniert wohl mit LATIN1, UTF8 hat nicht geklappt. Vielen Dank so weit. :slight_smile:

Mein nächstes Problem sind wohl NULL-strings. Die Datei hat viele. Ich fang schon mal an zu basteln. Und melde mich, wenn ich soweit bin. Falls ihr vorher schoin mal einen Tipp hättet, würde ich mich freuen.

kani=# SET CLIENT_ENCODING='UTF8';
SET

kani=# \encoding
UTF8

kani=# COPY agns
        FROM E'D:\\agns.csv'
        WITH DELIMITER ';' CSV HEADER
        ;
ERROR:  invalid byte sequence for encoding "UTF8": 0xdc52
HINT:  This error can also happen if the byte sequence does not match the encodi
ng expected by the server, which is controlled by "client_encoding".
CONTEXT:  COPY agns, line 4420

kani=# SET CLIENT_ENCODING='LATIN1';
SET

kani=# \encoding
LATIN1

kani=# COPY agns
        FROM E'D:\\agns.csv'
        WITH DELIMITER ';' CSV HEADER
        ;
ERROR:  missing data for column "foto"
CONTEXT:  COPY agns, line 57345: "DLT000002525;032015000;---;1;00001800;$HAEUP;4
524"