dbf nach PostgreSQL konvertieren

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"

Da wirst du wohl die Datei vorher per Skript auf einen vernünftigen Stand bringen müssen.

Das habe ich nicht mit nem Skript gemacht.
Trotzdem kann ich Vollzug melden:

kani=# COPY agns
        FROM E'D:\\agns k.csv'
        WITH
        CSV HEADER
        ;
COPY 57513

:smiley: :smiley: :smiley:

So sieht die csv aus:

→ Trennung durch ‘,’
→ auch, wenn z.B. die letzten drei Felder eines Datensatzes NULL sind, ‘,¶’
→ letzte leere Zeile am Textende (bei mir nur ¶) gelöscht

Sonderzeichen der csv erscheinen leider umgewandelt:
▄ für Ü
Í für Ö
− für Ä
ß bleibt ß
ä, ö und ü waren nicht in der csv enthalten.

Aber das ist wohl Thema eines neuen Newbie-Threads…

Bye and thanks

Herzlichen Glückwunsch und viel Spass weiterhin.

ich gehe mal davon aus das du dich mit DBF Dateien nicht so gut auskennst.
Ich komme nun von der Xbase (alle Version) Seite und “importiere” meine DBF nach PostgreSQL via libpq.dll per DLL Aufrufe.

zunächst die Frage :
woher kommen die DBF Dateien und sind da auch “Memo” Datei ( *.DBT, *.FPT) dabei ?
gibt es *.NTX oder *.CDX Dateien ?

DBF Dateien unterscheiden sich im “Header” und können “dBase”, “Clipper” oder “Foxpro” kompatibel sein.
“dBase” DBF sind fast immer OEM und auch bei Clipper wirst du in Deutschland meistens OEM finden.

“FoxPro” ist nun meistens ANSI und ist unter Windows Applicationen zu finden

dann gibt es noch DBF Datei, wie von PHP angelegt … da findet man “Sachen” … nicht kompatible.

\


nun bin ich noch PostgreSQL Newbie ( 25 Jahre Xbase ) und mir nicht 100% sicher …
ich muss PostgreSQL v9.x auf WIN1252 stellen und German_German.1252 statt UTF-8 wählen sonst kommen die “Umlaute” nicht hin ?


wenn du das Problem immer noch hast schau doch mal in das “http://www.xbaseforum.de
dort habe ich das “Import” Modul upgeloadet um aus Xbase++ per libpq.dll DBF Daten in eine PG Table zu schreiben.