Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 11

Thema: Fehlermeldung bei simplem SELECT über ODBC

  1. #1
    Werner1104 ist offline Neuer Benutzer
    Registriert seit
    03.09.2010
    Beiträge
    6

    Standard Fehlermeldung bei simplem SELECT über ODBC

    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,Ro wTimestamp,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. #2
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.055

    Standard

    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?
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  3. #3
    Werner1104 ist offline Neuer Benutzer
    Registriert seit
    03.09.2010
    Beiträge
    6

    Standard

    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. #4
    akretschmer ist gerade online Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.467

    Standard

    Zitat Zitat von Werner1104 Beitrag anzeigen
    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 ..
    Schau bitte in das LOG der DB, was *dort* steht.

    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  5. #5
    Werner1104 ist offline Neuer Benutzer
    Registriert seit
    03.09.2010
    Beiträge
    6

    Standard

    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,Ro wTimestamp,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. #6
    castorp ist offline Erfahrener Benutzer
    Registriert seit
    27.06.2009
    Beiträge
    524

    Standard

    Zitat Zitat von Werner1104 Beitrag anzeigen
    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
    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?
    A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'

  7. #7
    Werner1104 ist offline Neuer Benutzer
    Registriert seit
    03.09.2010
    Beiträge
    6

    Standard

    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=<pwd>; DATABASE=<dbname>;
    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. #8
    akretschmer ist gerade online Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.467

    Standard

    Zitat Zitat von Werner1104 Beitrag anzeigen
    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,Ro wTimestamp,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
    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
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  9. #9
    Werner1104 ist offline Neuer Benutzer
    Registriert seit
    03.09.2010
    Beiträge
    6

    Standard

    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. #10
    akretschmer ist gerade online Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.467

    Standard

    Zitat Zitat von Werner1104 Beitrag anzeigen

    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ß ?
    Nein, sorry.

    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Frage SELECT über mehrere TABLE
    Von Bloke im Forum SQL
    Antworten: 2
    Letzter Beitrag: 03.05.2010, 14:39
  2. Antworten: 2
    Letzter Beitrag: 07.04.2010, 14:02
  3. Antworten: 4
    Letzter Beitrag: 20.09.2009, 18:22
  4. Aus Excel über ODBC in eine OracleDB schreiben
    Von Wudy2000 im Forum externe Schnittstellen
    Antworten: 1
    Letzter Beitrag: 03.11.2006, 18:12
  5. PostGres ODBC über Internet sehr langsam
    Von Eser im Forum Allgemeines
    Antworten: 13
    Letzter Beitrag: 28.08.2006, 11:40

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Links: Tobias Bauer - IT- und Funkdienstleistungen   -   Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen   -   Funkforum