Fehlermeldung bei simplem SELECT über ODBC

Entwicklung externe Schnittstellen
1

Hallo,

ich arbeite zum ersten mal mit PostgreSQL und möchte PostgreSQL 9 als Ersatz für MS SQL evaluieren.

Deshalb habe ich PG 9 RC und ODBC driver 8.04.02 (ANSI) installiert.

Das Programm (EXE), das über den ODBC Treiber auf PG zugreift (Windows 32bit, VC++) verwendet ANSI strings, nicht Unicode.

Wenn ich das folgende simple SELECT :

SELECT Kurzzeichen,Name_Feld,EURO_Umr_Faktor,NKStellen,RowTimestamp,RowUserID,RowDDMFields,RowID FROM Waehrungen ORDER BY Kurzzeichen

aus pgAdminIII absetze, dann funktioniert das ganz problemlos und korrekt.
(Auch mit MS SQL und SQL Server Native Client 10.0 ODBC Driver funktioniert es korrekt).

Aber wenn ich genau dasselbe SELECT für dieselbe PG-Installation/Datenbank über den PG ODBC Treiber absetze,
dann bekomme ich:

SQLRetcode=-1
SqlState=42601, NativeError=7, MessageText=ERROR; Syntaxfehler bei »,«;

Ich habe schon etwas mit ENCODING=WIN1252 statt UTF-8 (beim Server) und UNICODE odbc driver statt ANSI driver rumprobiert;
das ergibt folgende Resultate:

Mit dem UNICODE driver taucht die Meldung nicht auf, aber die Daten sind komplett korrupt.

Mit ENCODING=WIN1252 (am Server) ist die Meldung ein bischen verschieden:
SQLRetcode=-1
SqlState=42601, NativeError=7, MessageText=ERROR; syntax error at »,«;

Außerdem habe ich schon probiert mit Server-Encoding UTF-8 (wird standardmäßig bei DB-Anlage eingerichtet) und
Client-Encoding auf “WIN”, “LATIN1”, “LATIN5”; aber das hilft alles auch nix.

Was ist da falsch ?

Funktioniert der ODBC Treiber 8.04.02 mit PG 9 nicht ?

Oder fehlen irgendwelche Einstellungen oder sind falsch ?

Vielen Dank im Voraus für jede Hilfe oder Hinweis !


Werner

2

Gegenfrage: kann es sein, dass du Daten in der Datenbank hast, die sich nur als UTF-8 darstellen lassen, aber nicht als Latin1 oder Win1252?

3

Nein, das kann nicht sein; das sind schlichte ANSI-Daten.
Ich habe auch schon testweise in PG eine Datenbank mit Encoding WIN1252 angelegt; mit der tritt dasselbe Problem auf.

Es scheint ja auch schon das SELECT-Statement als syntaktisch falsch betrachtet zu werden; vermutlich bevor überhaupt auf die tatsächlichen Daten zugegriffen wird.

Aber wie gesagt: Ich bin für jeden Hinweis, wo ich weiter suchen könnte, dankbar …

4

Schau bitte in das LOG der DB, was dort steht.

Andreas

5

habe jetzt im Log nachgesehen; dort steht folgendes dazu:
"
2010-09-03 13:40:04 CEST FEHLER: Syntaxfehler bei »,« bei Zeichen 1
2010-09-03 13:40:04 CEST ANWEISUNG: , “ctid” SELECT Kurzzeichen,Name_Feld,EURO_Umr_Faktor,NKStellen,RowTimestamp,RowUserID,RowDDMFields,RowID FROM Waehrungen ORDER BY Kurzzeichen
"
wobei ich nicht weiß, was der Anfang der Anweisung ', “ctid” ’ darstellt; in meiner SQL-Abfrage steht das jedenfalls nicht drin, sondern diese beginnt direkt mit SELECT

6

Baust Du die Anweisung evtl. dynamisch zusammen?

Mir ist auch noch das hier aufgefallen:
,Ro wTimestamp,

ich vermute, dass sollte eigentlich

,RowTimestamp,

also ohne Leerzeichen zwischen “o” und “w” sein, oder?

7

Ja, die Anweisung wird dynamisch generiert, aber ich bin ganz sicher, daß da kein , “ctid” am Anfang steht; die App gibt aufgrund der Fehlermeldung den Wortlaut der kompletten SQL-Anweisung aus, die den Fehler ergeben hat, und da steht das nicht drin.

bezüglich Blank in ,Ro wTimestamp : das steht im Log nicht drin; das muß (vermutlich wg. autom. Zeilenumbruch) beim Kopieren über Zwischenablage aus Log-File in den Forums-Editor mit reingekommen sein.

Die ODBC-Verbindung wird übrigens dsnless mit folgendem connectstring aufgebaut:
CONNECT=DRIVER={PostgreSQL ODBC Driver(ANSI)}; SERVERNAME=localhost; Username=postgres; Password=; DATABASE=;
dh. es werden keine speziellen Parameter für die ODBC-Verbindung eingestellt, sondern alles defaultmässig.

Auch auf Serverseite ist alles standardmässig installiert, dh. keine Änderungen in der postgresql.conf und Database mit vorgeschlagenden Standard-Parametern eingerichtet.

8

Wilde Vermutung: deine Tabelle hat keinen PK und der ODBC-Treiber versucht daher, die CTID-Column mit zu ziehen. Und wenn Deine Anwendung eh die SQL baut, gibt es vielleicht auch einstellbat SQL-Pass-Through, um dem ODBC-Treiber das rumpfuschen am übergebenen SQL zu verbieten. Aber, nochmals, ich vermute hier nur…

Andreas

9

Zunächst mal vielen Dank allen (ads, akretschmer, castorp), die bisher auf meine Anfrage geantwortet haben …

Die Tabelle hat schon einen PK; in PgAdmin wird das zugehörige SQL folgendermaßen angezeigt:
CREATE TABLE waehrungen
(
rowid serial NOT NULL,
rowtimestamp timestamp without time zone,
rowuserid integer,
rowddmfields text,
kurzzeichen character varying(4),
name_feld character varying(30),
euro_umr_faktor double precision,
nkstellen smallint,
CONSTRAINT waehrungen_pkey PRIMARY KEY (rowid)
)
WITH (
OIDS=FALSE
);
ALTER TABLE waehrungen OWNER TO postgres;

Das mit dem Pass-Through müsste ich noch eruieren; mit Pervasive SQL und MS SQL Server ODBC-Treibern, die ich bisher verwendet habe, gab es diesbezüglich noch nie Probleme.
Oder hast Du mir adhoc einen Tipp/Info dazu, wie man das machen kann/muß ?

10

Nein, sorry.

Andreas

11

nur zur Info:
Das Problem tritt mit den im PG 9 RC1 ausgelieferten ODBC-Treiber auf,
konnte inzwischen aber auf Hinweis von Hiroshi Inoue hin mit dem neuesten verfügbaren Treiber 8.4.0202 ( download page ) gelöst werden, dh. mit diesem tritt es nicht mehr auf.

Vielen Dank für Eure Hilfe !

Werner