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…
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.
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?!
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.
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
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.
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?
das Problem mit dem encoding scheint gelöst zu sein. Es funktioniert wohl mit LATIN1, UTF8 hat nicht geklappt. Vielen Dank so weit.
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"
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
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…
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.