Lazarus-Anbindung an PG-Datenbank

Guten Tag,

seit der Installation der Postgres-Version 8.3.4 habe ich folgendes Problem:

Wir haben ein Lazarus(Pascal)-Programm geschrieben, welches unter Windows automatisch eine Datenbank installiert; als Vorlage dient ein Postgis-Template (template_postgis).

Vom Programm werden einzelne SQL-Befehle aus einem Script an Postgres gesendet; unter 8.2 funktioniert das auch prima.

Unter 8.3.4 gibt es bei folgender Zeile (unterstrichen):

CREATE TABLE public.befundprofil (
id bigserial NOT NULL,
“name” varchar(128),
CONSTRAINT befundprofil_pkey PRIMARY KEY (id)) WITHOUT OIDS;

ALTER TABLE public.befundprofil OWNER TO “Administrator”;

INSERT INTO Befundprofil (ID,Name) VALUES (1,‘unbekannt’);
INSERT INTO Befundprofil (ID,Name) VALUES (2,‘Sandbodenprofile der Geest’);
INSERT INTO Befundprofil (ID,Name) VALUES (3,‘Sand mehr als 20 dm’);

eine Fehlermeldung:
Ungültige Bytesequenz für Kodierung “UTF8” 0xfc

Im PGADMIn wird das Script komplett verarbeitet, die Daten werden eingetragen.

Hat Jemand eine Idee?

Danke für Eure Hilfe.

Gruß Bernd

Setze im Script/Client das Client-Encoding passend.

Beispiel:

test=# show client_encoding;
 client_encoding
-----------------
 LATIN1
(1 row)

test=*# set client_encoding ='UTF8';
SET
test=*# show client_encoding;
 client_encoding
-----------------
 UTF8
(1 row)

Andreas

Danke, Andreas,

kannst Du mir sagen, warum die Fehlermeldung erst beim 3. Eintrag auftritt; die ersten beiden Einträge werden in die Datenbank eingefügt.

Erst die unterstrichene Zeile liefert die Fehlermeldung.

Gruß Bernd

Vielleicht ist da noch irgend ein Sonderzeichen drin?

Andreas

Nein, es sind keine Sonderzeichen drin; der emfohlene Eintrag hat auch keine Abhilfe gebracht.

Kann es daran liegen, dass der Server mit win1252-Encoding läuft; das Postgis-Template wird bei der Postgis-Installation automatisch als UTF8 installiert und somit auch als Vorlage verwendet?

Wenn ich die Vorlage ignoriere und einfach eine gleichnamige Datenbank ohne die Postgis-Einträge erstelle, dann wird das Script komplett verarbeitet.

Danke für Deine Mühe

Gruß aus Scheeßel

Bernd

Es ist ein Sonderzeichen drin, das ist die Stelle an der diese Fehlermeldung auftritt.

Übrigens sind Sonderzeichen je nach eingestelltem Encoding unterschiedlich. Wenn du also Latin1 hast werden jede Menge “normaler” Zeichen Probleme machen wenn diese aus UTF8 kommen. Deine Daten sind anscheinend Latin1 oder Windows 8 Bit oder so und du versuchst diese, in eine UTF8 Verbindung zu schreiben. Dann interpretiert UTF8 diverse Bits anders und versucht, aus dem aktuellen und einigen Folgebytes ein Zeichen zu lesen. Wenn das nicht funktioniert weil es das Zeichen nicht gibt … dann löst das genau diesen Fehler aus.

Guten Morgen,

heute kommt mein Kollege aus dem Urlaub; er meinte, wir sollten es mal mit dem Befehl

set client_encoding = ‘win1252’ (statt ‘utf8’)

und siehe da; das ganze Script wird abgearbeitet.

Aber WARUM ist es so? Ich möchte gern PostgreSQL verstehen… :confused:


Lieben Gruß

Bernd

Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es :wink:

Daten können in unterschiedlichen Encodings vorliegen, deine sind Windows Encoding, die Datenbank verlangt UTF8 Encoding. Glücklicherweise kann die Datenbank das automatisch umwandeln (solange sich das eine in dem anderen abbilden lässt), du musst der DB nur sagen, in welchen Encoding deine Daten vorliegen. Der Rest passiert automatisch.

Deine Daten stehen jetzt in UTF8 in der Datenbank. Wenn du sie wieder im Windows Encoding zurückhaben möchtest, setzt du client_encoding wieder passend und die DB liegert die Daten dann in deinem gewünschten Encoding zurück.

PostgreSQL: Documentation: Manuals: PostgreSQL 8.3: Character Set Support

Und hier noch etwas zum spielen: UTF Converter





mfg

fristo

Danke für die schnelle Antwort

Mit dem Primary key habe ich keine ahnung is das wenn ich auf design tabel gehe ob da ein Schlüssel ist oder nicht?

Und der Ahnhang ist nett, dass mit der Verschlüsselung weis ich schon nur kann ich mit set client_encoding = ‘win1252’ nichts anfangen da ich nicht weis wozu das ist, soll ich das im query analyzer compilieren oder was?

Und wenn ich das mache dann kommt außerdem diese Fehlermeldung
Line 1: Incorrect syntax near ‘=’.

Also wenn das möglich wäre und jemand weis wie das stupide für Idioten zu lösen ist dann wäre ich sehr dankbar.

Auch wenn ich selbst ungerne Skript Kiddys unterstütze aber sql ist ne Nummer für sich.

Ich vermute mal, du meinst meine Antwort auf deine heutige Frage. Aber warum Du nun in einem komplett anderen Thread antwortest wird wohl Dein Geheimnis bleiben.

Mit dem Primary key habe ich keine ahnung is das wenn ich auf design tabel gehe ob da ein Schlüssel ist oder nicht?

Google ist dein Freund - , dort mal den Begriff eintippen.


Und der Ahnhang ist nett, dass mit der Verschlüsselung weis ich schon nur kann ich mit set client_encoding = ‘win1252’ nichts anfangen da ich nicht weis wozu das ist, soll ich das im query analyzer compilieren oder was?

Und wenn ich das mache dann kommt außerdem diese Fehlermeldung
Line 1: Incorrect syntax near ‘=’.

Also wenn das möglich wäre und jemand weis wie das stupide für Idioten zu lösen ist dann wäre ich sehr dankbar.

Auch wenn ich selbst ungerne Skript Kiddys unterstütze aber sql ist ne Nummer für sich.

Dieses Kauderwelsch zu parsen ist mir nicht gelungen, sorry.

Andreas

Also das Programm was Du da benutzt, generiert im Hintergrund SQL, denn nur das Versteht Postgres. Bei SQL gibt es jedoch zwei Abteilungen.Das sogenannte DDL und das DML. DDL Statements sind solche SQL-Abfragen wie z.B CREATE TABLE oder CREATE INDEX (DDL = Data Definition Language). Mit DML kann man Sachen wie SELECT * FROM adressen machen und Daten abfragen und z.B mit UPDATE oder INSERT manipulieren (DML = Data Manipulation Language).
Mit dem DDL-STatement “CREATE PRIMARY KEY” wird auf eine bestimmte Spalte deiner Tabelle ein Index angelegt der dafür sorgen soll, das z.B via SELECT die
Daten schnelle ermittelt und die ganze Abfrage insgesammt wesentlich schneller ausgeführt . Gerade im Bereich Performance spielen die Indexe eine außerordentliche und wichtige Rolle mit der Du Dich möglichst bald einmal beschäftigen solltest.

nur kann ich mit set client_encoding = ‘win1252’ nichts anfangen da ich nicht weis wozu das ist, soll ich das im query analyzer compilieren oder was?

Ich schätze was Zeichenkodierung ist weißt Du schon. Postgres gestattet es Dir die Daten in deinen Tabellen auf Basis eines von Dir festzulegenden Zeichensatz zu kodieren. Früher hat man sehr oft einfach nur ASCII genommen, das ist für amerikanische Wörter auch kein Problem aber mit deutschen oder skandinavischen Umlauten und Sonderzeichen gibt es da Stress.Um es kurz zu machen: Die meisten Leute benutzen heute einfach die Codierung UTF-8, diese muss jedoch vom DB-Server (also in deinem Fall Postgres) und dem Client Programm (dein Lazarus Programm) verstanden und daher vorher eingestellt werden und dazu gibt es mehrere Möglichkeiten, eine ist es das an der Befehlszeile zu tun oder sich gewisser Hilfsmittel zu bedienen. Ich vermute mal das Du mit dem hervoragenden Client Programm PGAdmin3 arbeitest (so wie ich auch) das nun ja mittlerweile in der Stadardinstallation unter Windows immer vom Postgresinstaller mitinstalliert wird, anstatt direkt auf der der Befehlsshell wie unsere meisten Hardcore/Poweruser hier im Forum.Geh doch mal bitte im PGAdmin3 auf deine Lazarus Datenbank und überprüfe den DDL Abschnitt der ungefähr so aussehen müsste:

CREATE DATABASE mydb
WITH OWNER = admin
ENCODING = ‘UTF8’;

Wenn da etwas anderes steht als UTF8 würde ich das an deiner Stelle auf UTF8 ändern (musst Du zwar nicht, empfehle Ich Dir aber) möglicherweise muss Du deine Daten noch auf UTF8 umstellen, z.B dann wenn es auch im PGAdmin3 beim selektieren der Daten hier zu Umlautproblemen kommt. Als nächstes gehe im
PGAdmin3 bitte auf auf den Bereich “Login Rollen” und klicke den User mit Rechtsklick an mit dem sich dein Lazarus Programm verbindet möchte.Als nächstes siehst Du einige Reiter, einer davon heißt “Variablen”, wechsel bitte in diesen.In der Rubrik Variablen siehst Du nun ein Dropdownfeld mit Namen Variablennamen, dort wähle bitte die Variable mit namen “CLIENT_ENCODING” aus und trage als Variablenwert utf8 ein und klicke zum Abschluss noch auf den Hinzu/Ändern Button damit die Einstellungen gesichert werden.Der Effekt ist nun, das immer wenn sich dein Lazarusprogramm von nun an mit Postgres über diesen User verbindet das Clientencoding auf UTF-8 eingestellt ist, ich vermute mal dass nun dein Umlaut und Sonderzeichen Darstellungsproblem mit deinem Lazarus-Programm gelöst sein sollte. Wenn dem nicht so ist, schaue bitte in der Lazarus IDE nach ob Du das Coding auf UTF umstellen kannst.
Gruß, Marc

Nein. SQL kennt keine Indexe. Das PG einen Primary key als unique index und not null abbildet, ist ein Implentierungsdetail von PG. Es könnte also durchaus passieren, daß Deine Aussage bei anderen DB-Systemen schlicht falsch ist.

Andreas

Die Leute hier im Schulungsraum waren über das Detail auch ziemlich überrascht heute morgen. Ist halt nicht allgemein bekannt.

Empfehle halt Dein Buch. Da steht das drin.

Andreas

Ich beziehe mich hier auf Postgres und das hier ist ein Postgres Forum und der Fragesteller stellte diese Frage im Zusammenhang mit Postgres. Darüber hinaus dürfte es auch Dir nicht entgangen sein, das die sogenannten Implementierugnsdetails bezüglich ANSI und ISO wohl von keinem DB Hersteller besonders ernst genommen wurden und werden, daher ist die Postgres Sichtweise, gerade weil Postgres sich noch besser an die Standards hält ganz sicher nicht schlechteste, gerade weil die Unterscheide bei den führenden, anderen RDBMS Systemen gar nicht mal so drastisch sind, wie Du hier gerade glaubhaft machen willst.
Auf folgende Weise kann ich z.B

MySQL:
ALTER TABLE Customer ADD PRIMARY KEY (SID);

Oracle:
ALTER TABLE Customer ADD PRIMARY KEY (SID);

MS-SQL Server:
ALTER TABLE Customer ADD PRIMARY KEY (SID);

CrossDB jeder Tabelle nachträglich einen Primary Key verpassen, wo what?
Fachlich ist deine Aussage daher eher nichtssagend und für jemanden der von SQL nicht besonders viel Ahnung hat und das das ganze versucht erstmal mit einem GUI Frontend wie PGadmin3 zu verstehen nicht besonders hilfreich.

Nein.

Andreas

Aha. Wir sind also kein Postgres Forum? Ist ja mal ganz was neues :slight_smile:

Doch. Aber der Fragesteller verwendet was anderes.

Andreas