hawkmaster: Probleme nach Migration Postgres, SQLSTATE[42P01]

Hallo zusammen,
Ich versuche gerade mal meine MySQL db nach Postgres zu migrieren.
Die Migration und alle Daten scheinen auf den ersten Blick ok zu sein.
Meine PHP Anwendung nutzt PDO zur Verbindung.
Ich habe die Connection auf Postgres geändert.
Ein erster Aufruf bringt nun aber gleich folgenden Fehler:

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42P01]: Undefined table: 7 FEHLER: Relation »ir_language« existiert nicht LINE 1 in db.inc.php on line 3864

Die Tabelle ir_language existiert aber. Auch scheint der Inhalt ok zu sein.
Es handelt sich eigentlich auch nur um einen einfachen Select:

  
function getLanguages(){  
global $DBO;  
$dbSelectLanguages = $DBO->query("SELECT LanguageID,LanguageDescription,TextID,CountryCode,ConfigName FROM ir_language ORDER BY LanguageID ASC");  
$languages_arr = $dbSelectLanguages->fetchAll(PDO::FETCH_ASSOC);  
return $languages_arr;  
}  

Ich habe leider noch überhaupt keine Erfahrung mit Postgres.
Kann mir jemand einen Tipp geben, was dies sein könnte?

vielen Dank und viele Grüße
hawk

  1. Hallo,

    Ich versuche gerade mal meine MySQL db nach Postgres zu migrieren.
    Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42P01]: Undefined table: 7 FEHLER: Relation »ir_language« existiert nicht LINE 1 in db.inc.php on line 3864

    Die Tabelle ir_language existiert aber.

    möglicherweise in einem Schema, in dem nicht gesucht wird (siehe 5.7.3 The Schema Search Path).

    Freundliche Grüße

    Vinzenz

    1. Hallo Vinzenz,

      möglicherweise in einem Schema, in dem nicht gesucht wird (siehe 5.7.3 The Schema Search Path).

      Kannst du mir vielleicht noch ein paar Hinweise geben? Es ist alles so neu. Ich habe das Tool pgAdmin. Hier sehe ich die migrierte Datenbank "testdb".Darunter gibt es "Schemata". Einmal "testdb" und einmal "public" im Schema "testdb" sehe ich dann die ganzen migrierten Tabellen darunter auch die Tabelle "ir_language".

      Habe ich was falsch gemacht beim migrieren?

      vielen Dank und viele Grüße
      hawk

    2. Hallo
      so jetzt habe ich das Problem etwas einkreisen können.
      Der Fehler kam nämlich auch im pgAdmin.

      Ich muss die Abfrage so ändern:

      SELECT "LanguageID","LanguageDescription","TextID","CountryCode","ConfigName" FROM testdb.ir_language ORDER BY "LanguageID" ASC

      Was mich aber wundert und vor Probleme stellt.
      Muss man bei Postgres alle Spaltennamen in Hochkomma stellen?

      Wenn ich diese weglasse, und es so versuche:
      SELECT LanguageID,LanguageDescription,TextID,CountryCode,ConfigName FROM testdb.ir_language ORDER BY LanguageID ASC

      dann gibt es die Fehlermeldung:
      FEHLER:  Spalte »languageid« existiert nicht
      LINE 1: SELECT LanguageID,LanguageDescription,"TextID","CountryCode"...

      Das wäre etwas ungünstig denn sonst müsste ich alle meine bisherigen Abfragen umändern.

      vielen Dank und viele Grüße
      hawk

      1. Hallo,

        Ich muss die Abfrage so ändern:

        SELECT "LanguageID","LanguageDescription","TextID","CountryCode","ConfigName" FROM testdb.ir_language ORDER BY "LanguageID" ASC

        Was mich aber wundert und vor Probleme stellt.
        Muss man bei Postgres alle Spaltennamen in Hochkomma stellen?

        a) die doppelten Anführungszeichen sind ganz normale ANSI QUOTES.
        b) Möglicherweise hat Dein Migrationswerkzeug Deine Spaltennamen bei der
           Migration allesamt gequoted, so wie es zum Beispiel phpMyAdmin für MySQL
           macht.

        Das hat aber weitreichende Konsequenzen:
        PostgreSQL behandelt ungequotete Identifier case-insensitiv (und wandelt sie intern zu komplett kleingeschriebenen Namen um - SQL-Standard ist übrigens Großschreibung), gequotete Identifier behandelt PostgreSQL dagegen case-sensitiv und Du musst sie bei gemischter Groß-/Kleinschreibung anschließend immer quoten, siehe auch entsprechender Handbuchabschnitt (4.1.1 Identifiers and Key Words), ich zitiere den letzten Satz dieses Abschnitts:

        <zitat>
            If you want to write portable applications you are advised to always
            quote a particular name or never quote it.
        </zitat>

        Das lernst Du derzeit auf die harte Tour. Hast Du Datums-/Zeitliterale oder Funktionen verwendet? Wenn ja, dann stelle Dich bitte auf die Prüfung der betroffenen Statements ein ...

        (DBMS-) Plattformübergreifendes SQL ist eine Illusion.

        Freundliche Grüße

        Vinzenz

        1. Hallo Vinzenz,

          b) Möglicherweise hat Dein Migrationswerkzeug Deine Spaltennamen bei der
             Migration allesamt gequoted, so wie es zum Beispiel phpMyAdmin für MySQL

          Ich habe mir das nochmals in dem PGAdmin Tool angeschaut. Ich glaube nicht das es an dem Migrationstool liegt. Auch sind die Spaltennamen von der Schreibweise alle identisch und auch nicht in Hochkommas.
          Auch wenn ich eine neue Testtabelle anlege scheint die Abfrage immer in Hochkomma zu sein.
          Habe eine Tabelle test mit einer Spalte LangID angelegt.

          -- Column: "LangID"

          -- ALTER TABLE test DROP COLUMN "LangID";

          ALTER TABLE test ADD COLUMN "LangID" integer;
          ALTER TABLE test ALTER COLUMN "LangID" SET DEFAULT 0;

          (DBMS-) Plattformübergreifendes SQL ist eine Illusion.

          Ja ich glaube davon muss ich mich wohl verabschieden. Obwohl ich es mittels PDO nun hinbekommen habe, dass ich zwischen MySQL und MS SQL umschalten kann.
          Jetzt wäre halt noch Postgres eine Hürde wobei es eine Überlegung dauerhaft  ganz zu Postgres zu wechseln

          vielen Dank und viele Grüße
          hawk

          1. Hallo,

            Auch wenn ich eine neue Testtabelle anlege scheint die Abfrage immer in Hochkomma zu sein.
            Habe eine Tabelle test mit einer Spalte LangID angelegt.

            -- Column: "LangID"

            -- ALTER TABLE test DROP COLUMN "LangID";

            ALTER TABLE test ADD COLUMN "LangID" integer;

            Lass Doch die Anführungszeichen weg. Dann ist der Spaltenname case-insensitive:

            ALTER TABLE test ADD COLUMN LangID integer;

            Freundliche Grüße

            Vinzenz

  2. hi,

    Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42P01]: Undefined table: 7 FEHLER: Relation »ir_language« existiert nicht LINE 1 in db.inc.php on line 3864

    Uncaught Exception, d.h., deine Code, der eine Exception möglicherweise auswerfen kann, muss in try{} catch{} Blöcken notiert sein.

    hth

    Hotti

    1. Hallo,

      Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42P01]: Undefined table: 7 FEHLER: Relation »ir_language« existiert nicht LINE 1 in db.inc.php on line 3864

      Uncaught Exception, d.h., deine Code, der eine Exception möglicherweise auswerfen kann, muss in try{} catch{} Blöcken notiert sein.

      soll der gute Falknermeister x! * a! * b! * c! * ... verschiedene Schreibweisen für seine x Buchstaben langen Tabellen- und a bis ... Zeichen langen Spaltennamen in entsprechend vielen Catch-Blöcken notieren und mit den nicht passenden Notationen das Fehlerlog vollspammen? Vielleicht mit Gaius' (noch zu schreibendem) Fehlerbehandlungswerkzeug die fehlerhaften Versuche abhaken ...

      Freundliche Grüße

      Vinzenz

      1. Hallo,

        Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42P01]: Undefined table: 7 FEHLER: Relation »ir_language« existiert nicht LINE 1 in db.inc.php on line 3864

        Uncaught Exception, d.h., deine Code, der eine Exception möglicherweise auswerfen kann, muss in try{} catch{} Blöcken notiert sein.

        soll der gute Falknermeister x! * a! * b! * c! * ... verschiedene Schreibweisen für seine x Buchstaben langen Tabellen- und a bis ... Zeichen langen Spaltennamen in entsprechend vielen Catch-Blöcken notieren und mit den nicht passenden Notationen das Fehlerlog vollspammen?

        Jede Programmiersprache hat ein ExceptionModel, hier findest Du die Antwort. Da steht drin, wo Exceptions zu erwarten und wie die zu behandeln sind. Btw., Java-Programmierer sehen diese Meldung "Uncaught Exception..." öfter ;-)

        Vielleicht mit Gaius' (noch zu schreibendem) Fehlerbehandlungswerkzeug die fehlerhaften Versuche abhaken ...

        Das ist keine Fehlerbehandlung sondern ein Tracken. Etwas ungewöhnlich, aber wer weiß was dahinter steckt.

        Viele Grüße,
        Hotti