Fehlermeldung bei Import

Hallo,

ich versuche schon das ganze Wochenende, Daten in eine bestehende POSTGRE-Datenbank namens testdb eine Tabelle mit Namen a357_fpl zu integrieren. Die SQL-Befehle dazu habe ich mit einer Freeware aus einer ACCESS-Datenbank exportieren lassen.

Die Tabelle ist folgendermaßen deklariert:

*CREATE TABLE “a357_fpl”
(
id_nr varchar(11),
sig numeric,
falsifik numeric,
erstnenn numeric,
objekt varchar(30),
zeitstell varchar(48),
nutzung varchar(20),
erhalt numeric,
gefahr numeric,
ndk numeric,
erf_stat numeric,
gruppe_nr numeric,
lokguete numeric,
tk25 varchar(4),
tk25_f numeric,
dgk5 varchar(8),
dgk5_f numeric,
r_von numeric,
r_bis numeric,
h_von numeric,
h_bis numeric,
nn_von numeric,
nn_bis numeric,
flur varchar(4),
flst varchar(13),
flurname varchar(30),
auffind varchar(21),
benachr varchar(10),
wpl numeric,
zeit_bis varchar(48)
)
*

mit dem Kommandozeilentool importiere ich die Tabelle mit dem Befehl:*psql -d testdb -f a357_fpl.sql
*

es erscheint prompt folgende Fehlermeldung:*1205: ERROR: column “35710500093” does not exist
*

Bis zur Zeile 1204 wurden die Befehle also anstandslos abgearbeitet; die vorletzte und letzte Zeile sehen folgendermaßen aus:*INSERT INTO a357_fpl
VALUES (“35710500092”,6200000,1,1,“Schlackenplatz”,“unbekannt”,“unbekannt”,0,0,1,0,0,3,“2520”,0,"2520/19 ",0,3500320,0,5922565,0,0,0,NULL,NULL,NULL,“gezielte Begehung”,NULL,10,NULL);

INSERT INTO a357_fpl
VALUES (“35710500093”,8100001,1,1,“Kreuzstein”,“unbekannt”,“Ackerland”,4,0,0,0,0,3,“2519”,0,"2519/17 ",0,3497540,0,5924470,0,0,0,NULL,NULL,“Ströhen”,“unbekannt”,NULL,10,“unbekannt”);
*

Seht Ihr den Fehler; ich habe resigniert…

Das will bei mir allerdings nicht viel heißen; ich komme aus der COBOL-Programmierung und bin absoluter POSTGRE-Neuling.

Gruß Bernd :wink:

hi bernd!

freut mich zu hören das noch mehr leute mit cobol arbeiten! ich mach das auch teilweise noch wobei ich neue programme in rpg schreib und nur noch die alten cobol dinosaurier warte :wink:

aber zurück zum thema…

was passiert, wenn du den letzten geposten insert alleine ausführst? dann müsstest du da doch eine fehlermeldung bekommen. vielleicht hilft dir diese schon weiter…

cu tb.

Hallo,

danke für Deine schnelle Antwort.

Ich war leider in einer Firma, die insolvent wurde, langzeitarbeitslos; jetzt als Ein-Euro-Jobber in der Archäologie tätig. Meine COBOL-Projekte laufen aber noch immer und ich pflege sie in gemeldeter Nebentätigkeit.

Habe, wie Du sagtest, die letzten beiden Zeilen separat ausgeführt; der Fehler muss in der vorletzten Zeile (s.o.) sein.

Fehlermeldung lautet jetzt:

Syntax-Error at or near "INSERT"

In der letzten Zeile kommt dann, wie vorher:

column “35710500093” does not exist

Danke für Deine freundliche Hilfe

Bernd :slight_smile:

hm, also ich seh jetzt bei diesen insert keinen syntaktischen fehler… also eigentlich sind die inserts sauber…

ist es absicht das hier teilweise leerzeichen in den strings sind?

cu tb.

Hallo,

die ACCESS-Datenbank wurde eigentlich “just-for-fun” angelegt und es existieren jede Menge Tippfehler darin.

Da die Fehlermeldung sich auf den ersten INSERT bezieht, werde ich mir die vor-vorletzte Zeile nochmal genau ansehen, die folgendermaßen lautet:

INSERT INTO a357_fpl VALUES(“35710500091”,100000,1,1,“Einzelfund”,“unbekannt”,“unbekannt”,0,0,0,0,0,3,“2520”,0,"2520/13 ",0,3500000,3500300,5924000,5924250,0,0,NULL,NULL,“Hohe Kamp”,“unbekannt”,NULL,10,NULL);
Gruß Bernd :slight_smile:

hm… aber der eintrag ist eigentlich auch sauber… ich verstehs net. vielleicht überseh ich aber auch nur ne kleinigkeit was ich jetzt mal nicht ausschließen möchte :wink:

cu tb.

Genau DAS befürchte ich bei mir auch; ich kann auch nichts entdecken… :smiley:

Gruß Bernd :wink:

Hallo Bernd,

nicht resignieren. Das ist mit Sicherheit ein typischer Anfängerfehler.

Ich vermute mal, dass die Datenbank aufgrund falscher SERVER_ENCODING keine Umlaute, wie in “Ströhen” das ö, mag. Default lautet die SERVER_ENCODING immer ASCII.

Welche SERVER_ENCODING hast Du bei der Erstellung der Datenbank angegeben?

Da Du Anfänger bist, solltest Du Dir PgAdmin installieren. Die grafische Oberfläche hilft Dir vieles einfacher zu verstehen.



mfg

fristo

Hallo Fristo,

die Umlaute hatte ich auch als Fehlerquelle in Verdacht; da es sich aber um die ungefähr 1100. Zeile handelt und vorher auch schon reichlich Umlaute benutzt wurden, habe ich diese Fehlermöglichkeit für mich ausgeklammert.

PGADMIN habe ich auch in Gebrauch; dort waren die Fehlermeldungen noch abstruser und ich bin deshalb auf die Kommandozeile gewechselt.
PGADMIN meldete mir einen Fehler bei Zeichen soundso near eines “,”; jetzt kommt ne wirklich dumme Frage von mir…wie finde ich im PGADMIN das soundsovielte Zeichen?
Hatte mir als Editor PROTON installiert, aber der gab auch nur Zeile und Spalte aus.


Danke für Deine Hilfe.

Bernd :slight_smile:

Hallo Bernd,

Keine Change, außer Du zählst die Zeichen händisch. Ich habe bisher auch noch keinen Editor gefunden, der ständig die Nummer des Zeichens angibt. Die Angabe der Position eines Fehlers in PostgreSQL nicht mehr zu überbieten. Da hatte man selbst in den Anfängen der Programmierung schon bessere Ideen.

Zu deinem Problem. Ich kenne ähnliche Fehlermeldungen auch von Scripten her. Vermutlich ist ein Zeichen, welches nicht in dem Zeichensatz CLIENT_ENCODING enthalten ist, in der Import-Datei vorhanden. Dies ist die wahrscheinlichste Möglichkeit, da beim Import eine Code-Konvertierung vom Zeichensatz CLIENT_ENCODING zu dem Zeichensatz SERVER_ENCODING erfolgt. Dieses wird von PostgreSQL sehr strikt gehandhabt.

Bei mir hat bei den Fehlermeldungen immer geholfen, wenn ich das Script an der Stelle neu geschrieben habe. Das sinnvollst ist daher, dass Du die Inport-Datei an der Stelle der Fehlermeldung auftrennst, und die Zeichen im binären Format untersuchst. Schau dir aber vorher genau den Zeichensatz der CLIENT_ENCODING an, an welcher Stelle wirklich ein gültiges Zeichen ist.


PS: Wenn Du über PgAdmin importierst, muss Du vor dem Importieren immer den Zeichensatz der CLIENT_ENCODING (den Zeichensatz der Import-Datei) programmieren, da PgAdmin selbst mit der CLIENT_ENCODING UTF-8 arbeitet. Anschließend die CLIENT_ENCODING wieder als UTF-8 programmieren, ansonsten stellt PgAdmin nicht immer die richtigen Zeichen dar.



mfg

fristo

Hallo Fristo,

dann werde ich Datenbank neu erstellen; da wir die Spatial-Erweiterung nutzen, eine schöne Prozedur :wink:

Die alte Bank war mit SQL-ASSCI erstellt worden, ich werde jetzt UTF-8 bzw. LATIN-1 nutzen, vielleicht klappts dann.

Nochmals dankeschön für Deine Tipps :slight_smile:


Gruß Bernd

Hallo,

habe beides ausprobiert; die Fehlermeldungen sind geblieben.

Es wird sicher, wie fristo vermutet, ein Anfängerfehler sein…aber welcher?

Gruß Bernd :slight_smile:

Hallo,

habe POSTGRES jetzt soweit, dass die Tabelle erstellt und teilweise mit Daten gefüllt wird.

Merkwürdig ist:

Im CREATE möchte POSTGRES bei mir doppelte Anführungszeichen haben, bei den INSERTS einfache.

Gruß Bernd .)

Hallo Bernd,

nicht merkwürdig. Hier fehlt Dir das Know-How.

Für Tabellen- und Spaltennamen gilt: Ist der Name mit dem "-Zeichen umgeben , so wird der Name in der angegebenen Schreibweise übernommen. Ohne das "-Zeichen erfolgt immer die Konvertierung zu kleinen Buchstaben. Dieses ist der Default-Modus.

Beim INSERT-Befehl gilt folgendes: Für Tabellen- und Spaltennamen das eben beschriebene. Für VALUES gilt bei Textfelder das '-Zeichen, da der importierte Text als CONSTANTE angesehen wird.



mfg

fristo