pg-datenbanktablle mit OOo2.3 füllen

Hallo,
in einer vorgegebenen Anwendung (hier lx-office) mit PG-Datenbank möchte ich vorhendene Tabelle mit OOo-Cac und OOo-Base bearbeiten bzw. eine neue Tabelle anlegen.
OOo desshalb, weil es vom Handling her sehr komfortabel ist und die Tabellenvorlagen sich relativ leicht anpassen lassen.
Die Handarbeit an der Ursprungsdatei zur Vorbeiteung einer .csv-datei für COPY unter psql ist relativ aufwendig und soll daher nur als zweitrangige Lösung ins Auge gefasst erden.
OOo ist über ODBC mit der PostgreSQL-Datenbank verbunden.
Beim Kopieren der maktierten Datensätze tritt jedoch folgender Fehler auf:
(die OOo-Leute hatte ich wegen diese Verhaltens bereits kontaktiert, jedoch ohne Erfolg)
Alle Daten als Text (bis 256 Zeichen), als Integer, als Datum und auch als Dezimalzahl werden fehlerfrei kopiert. Ausnahme sind lange Texte mit 1000 bis 3000 Zeichen. Hier finde ich in der PG-Tabelle lediglich den Eintag “0” wieder.
Es scheint, als ob PG daraus eine Zahl macht, warum?
Das Tabellen Feld in PG habe ich als “memo” festgelegt, um damit diese längeren Texte speichen zu können. Bei “varchar” werden ja nur 256 Zeichen gespeichert.
Wo kann ich mit meiner Ursachenforschung ansetzen?
Wo könnte mein Fehler liegen?
Dieser Fehler tritt bei unterschiedlichen Clients (w2k, xp, Suse, Debian) auf und auch bei uneterschiedleichen Servern (Debian mit PG 8.1 bzw. PG 8.2).
Als ODBC-Treiber habe ich die auf der PostgreSQL-Seite angebotenen verwendet.
Gruß
Armin

Vermutlich macht das nicht PG, sondern der ODBC-Treiber.

Das Tabellen Feld in PG habe ich als “memo” festgelegt, um damit diese längeren Texte speichen zu können. Bei

Den Datentyp ‘memo’ kennt PG nicht.

“varchar” werden ja nur 256 Zeichen gespeichert.

Falsch. If character varying is used without length specifier, the type accepts strings of any size. Zitat aus der lesenswerten Doku.

Wo kann ich mit meiner Ursachenforschung ansetzen?
Wo könnte mein Fehler liegen?
Dieser Fehler tritt bei unterschiedlichen Clients (w2k, xp, Suse, Debian) auf und auch bei uneterschiedleichen Servern (Debian mit PG 8.1 bzw. PG 8.2).
Als ODBC-Treiber habe ich die auf der PostgreSQL-Seite angebotenen verwendet.
Gruß
Armin

Ich bin kein Freund von Klicki-Tools, ich kann da Dir auch ned wirklich helfen. Ich bin ja nach wie vor der Meinung, ein ‘create table foo (bar int, batz text);’ ist schneller getippt als man ominöse Fehler in einer GUI gefixt hat…


Andreas

[quote=“akretschmer”]Vermutlich macht das nicht PG, sondern der ODBC-Treiber.
o.k. hatte ich ach zuerst vermutet, da jedoch Microsoft und Linux unterschiedliche ODBC-Treiber verwenden, müsste der Fehler ja ich beiden ODBC-Treibern vorliegen.

Den Datentyp ‘memo’ kennt PG nicht.
o.k. aber auch das Ändern der betroffenen spalten in ‘text’ brachte das gleiche Ergebnis.

Falsch. If character varying is used without length specifier, the type accepts strings of any size. Zitat aus der lesenswerten Doku.
mm–. dann wird varchar in OOo anders inetpretiert oder ist dort auf 256 Zeichen festgelegt.

Ich bin kein Freund von Klicki-Tools, ich kann da Dir auch ned wirklich helfen. Ich bin ja nach wie vor der Meinung, ein ‘create table foo (bar int, batz text);’ ist schneller getippt als man ominöse Fehler in einer GUI gefixt hat…

Ich kann Dich ja irgend wie verstehen, nur ich suchte nach einer Lösung, die ich mit etwas erklärenden Text auch anderen Personen übertragen kann, die sich in der Konsole nicht so gut zu Hause fühlen.

Angenommen die Tabelle als solches ist erzeugt und mit Daten gefüllt, bis auf 4 Spalten, in denen z.Z. eine ‘0’ je Zeile steht.
Jetzt brauche ich Deine Hilfestellung
Wie bekomme ich jetzt aus der ,csv-Tabelle diese 4 Spalten in meine Datenbanktabelle?
Wenn ich COPY richtig verstehen, werden ja die nicht definierten Spalten mit ‘default’- Werten oder NULL überschrieben.
Mit UPDATE kann ich immer nur eine Zeile bearbeiten.
Bitte entschuldige die dummen Fragen aber so bewandert bin ich noch nicht und außerden schon ein wenig älter als Du.
Gruß
Armin

Wie nun, die Tabelle ist erstellt und gefüllt (und Du willst nur den Inhalt einiger Spalten ändern), oder aber eine leere Tabelle?

Fall1:
Du brauchst eine Verbindung zwischen dieser Tabelle und den vorliegenden Daten. Ein PK drängt sich da förmlich auf. Der Rest ist simples SQL.

Fall2: noch einfacher als Fall1.

Wenn ich COPY richtig verstehen, werden ja die nicht definierten Spalten mit ‘default’- Werten oder NULL überschrieben.

Darin sehe ich kein Problem.

Mit UPDATE kann ich immer nur eine Zeile bearbeiten.

Nein. Und ich bin sehr, sehr froh, daß PG mit Transaktionen gut zurecht kommt, weil ein WHERE bei einem UPDATE kann ohne Transaktionen echt schmerzhaft sein. Spätestens dann merkst man, das ein UPDATE deutlich mehr als eine Zeile bearbeiten kann…

Bitte entschuldige die dummen Fragen aber so bewandert bin ich noch nicht und außerden schon ein wenig älter als Du.
Gruß
Armin

Kein Problem, aber ob Du älter als ich bist ist diskussionswürdig. Ich für mich kann mit Stolz sagen, daß meine Kinder mich schon mit meinem (bald auch ihrem) Auto spazieren fahren können (Führerschein mit 17, you know?). Okay, mein jüngstes Kind macht allerdings noch in die Windeln…


Andreas