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

Thema: psycopg2.InternalError (Python)

  1. #1
    Hannes23 ist offline Benutzer
    Registriert seit
    07.05.2010
    Beiträge
    39

    Standard psycopg2.InternalError (Python)

    Hallo zusammen,

    ich bekomme beim Schicken einer SQL-Abfrage von Python aus an eine Postgres-DB folgende Fehlermeldung, was mich langsam echt zur Verzweiflung bringt :-(

    Code:
    psycopg2.InternalError: current transaction is  aborted, commands ignored until end of transaction block
    Der Code selbst macht eigentlich nix wildes und hat bisher auch immer funktioniert. Er sieht in etwa so aus:

    Code:
    sql="""SELECT * from tabelle where  tabelle.gueltigvon < %s AND
              tabelle.ablaufdatum = %s 
              ... """
    
            parameter=(datum, datum, datum, datum,  nummer, nummer, nummer, nummer, nummer)
            curs.execute(sql,  parameter)
            row = curs.fetchall()
    (natürlich kommen auch genau 9x %s vor, so dass datum und nummer jeweils eingesetzt wird. Ich hab das hier nur der Einfachheit halber verkürzt. Mit der Abfrage selbst, sollte es m.E. nichts zu tun haben)

    Kann mir da jemand weiterhelfen??

    Viele Grüße und vielen Dank!!
    Hannes
    Geändert von Hannes23 (12.07.2010 um 17:49 Uhr)

  2. #2
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.020

    Standard

    Anscheinend ist dieser Code nicht dein Problem sondern ein Befehl, der vorher ausgeführt wurde.
    Der hat einen Fehler verursacht und daraufhin wurde deine Transaktion beendet.

    Ev. findest du im Log des Servers weitere Informationen.
    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
    Hannes23 ist offline Benutzer
    Registriert seit
    07.05.2010
    Beiträge
    39

    Standard

    Hallo ads,

    danke für die schnelle Antwort!

    Im Server-Logfile sehe ich im Grunde nochmal das, was mir auch Python ausgibt: Meine SQL-Abfrage zusammen mit der Meldug
    current transaction is aborted, commands ignored until end of transaction block

    An anderer Stelle habe ich gelesen, dass ggf. ein "Rollback" bzw. ein "Commit" das Problem einer fehlerhaften Transaktion beheben könnte.
    Ich würde das ja ausprobieren, bin mir aber der Auswirkungen nicht so ganz im Klaren. Es geht um eine produktive Datenbank, auf die
    über eine Software ständig neue Abfragen ausgeführt werden (auch seit dem Auftreten des Fehlers waren es wieder viele). Bewirkt denn
    ein Rollback dann nur, dass fehlerhafte Transaktionen "zurückgerollt" werden oder muss ich auch Angst haben, dass sämtliche INSERTS oder
    UPDATES seit Auftreten des Fehlers "rückgängig" gemacht werden?

  4. #4
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.020

    Standard

    Alle Aktionen, die seit dem Start der Transaktion durchgeführt wurden, werden zurückgerollt.

    Klingt etwas makaber, aber: ist sowieso egal wieviele Aktionen in der Transaktion ausgeführt wurden. Sobald die Transaktion durch einen Fehler abgebrochen wurde, sind die Änderungen sowieso verloren.

    Für dich wichtig ist: diese Fehlermeldung wird erst beim Ausführen von Anweisungen nach einem Fehler verursacht. Der eigentliche Fehler tritt irgendwo früher auf. Den musst du finden.
    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

  5. #5
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Nähe Dresden
    Beiträge
    5.337

    Standard

    Zitat Zitat von Hannes23 Beitrag anzeigen
    Hallo ads,

    danke für die schnelle Antwort!

    Im Server-Logfile sehe ich im Grunde nochmal das, was mir auch Python ausgibt: Meine SQL-Abfrage zusammen mit der Meldug
    current transaction is aborted, commands ignored until end of transaction block

    An anderer Stelle habe ich gelesen, dass ggf. ein "Rollback" bzw. ein "Commit" das Problem einer fehlerhaften Transaktion beheben könnte.
    Ich würde das ja ausprobieren, bin mir aber der Auswirkungen nicht so ganz im Klaren. Es geht um eine produktive Datenbank, auf die
    über eine Software ständig neue Abfragen ausgeführt werden (auch seit dem Auftreten des Fehlers waren es wieder viele). Bewirkt denn
    ein Rollback dann nur, dass fehlerhafte Transaktionen "zurückgerollt" werden oder muss ich auch Angst haben, dass sämtliche INSERTS oder
    UPDATES seit Auftreten des Fehlers "rückgängig" gemacht werden?
    Mir scheint, Du hast das Konzept einer Transaktion nicht verstanden. Angenommen, Du startest eine Transaktion (TX), und in dieser TX machst Du erfolgreich erst einmal 100 Inserts. Und dann aber leider eine mit ungültigen Daten. Ab dann ist die TX ungültig. Du kannst weiter die DB mit Inserts bewerfen - es bringt aber nix. Du kommst da nur mittels ROLLBACK (oder auch COMMIT) raus, beides wird aber ein Rollback auslösen, und zwar für alles, was in dieser TX passiert ist. Dies gilt auch für die ersten 100 erfolgreichen Inserts.

    So, und nun merkst Du Dir, daß nach jeder Aktion (Insert, Select, ...) man den Rückgabewert prüft, ob die Aktion erfolgreich war. Tust Du das nicht, kannst Du nun nicht mehr nachvollziehen, ob es das erste, zehnte oder hunderste Insert war, welches Dir Deine TX zerhauen hat.

    Ach ja: ich bin kein Phyton-Experte, aber vielleicht ist ja auch das eingang von Dir gezeigte schon falsch, nämlich dann, wenn PG Dein Datum nicht als Datum erkennt. Was genau bekommt denn der PG-Server als SQL übergeben?


    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

  6. #6
    Hannes23 ist offline Benutzer
    Registriert seit
    07.05.2010
    Beiträge
    39

    Standard

    Ah, ok. Das heißt, es geht logischerweise nur um ein Rollback dieser Transaktion, in der mein Fehler auftritt (in einem Skript). Wenn dann nebenbei andere Programme Querys auf die gleiche Datenbank ausführen, hat das damit nichts zu tun. Die sind weiterhin ausgeführt worden und sind auch vom Rollback nicht betroffen.

    Danke für den Hinweis, den Fehler im Programm VOR der Stelle mit dem fehlerspuckenden Query zu suchen. Dass heißt, dass in meinem Python-Code irgendwo davor ein Fehler drin sein wird. Aber ist denn dann ein Rollback überhaupt noch nötig?

  7. #7
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.020

    Standard

    Zitat Zitat von Hannes23 Beitrag anzeigen
    Danke für den Hinweis, den Fehler im Programm VOR der Stelle mit dem fehlerspuckenden Query zu suchen. Dass heißt, dass in meinem Python-Code irgendwo davor ein Fehler drin sein wird.
    An dieser Stelle noch mal der eindringliche Hinweis, den Rückgabewert jeder Anfrage zu prüfen.
    Python kann dir dafür sicher nette Exceptions auslösen, die du abfangen kannst.


    Aber ist denn dann ein Rollback überhaupt noch nötig?
    Sicher musst du das. Woher soll die Datenbank sonst wissen, dass du deinen Fehler bemerkt hast?
    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

  8. #8
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Nähe Dresden
    Beiträge
    5.337

    Standard

    Zitat Zitat von Hannes23 Beitrag anzeigen
    Ah, ok. Das heißt, es geht logischerweise nur um ein Rollback dieser Transaktion, in der mein Fehler auftritt (in einem Skript). Wenn dann nebenbei andere Programme Querys auf die gleiche Datenbank ausführen, hat das damit nichts zu tun. Die sind weiterhin ausgeführt worden und sind auch vom Rollback nicht betroffen.

    ACK.

    Danke für den Hinweis, den Fehler im Programm VOR der Stelle mit dem fehlerspuckenden Query zu suchen. Dass heißt, dass in meinem Python-Code irgendwo davor ein Fehler drin sein wird. Aber ist denn dann ein Rollback überhaupt noch nötig?
    Ja. Was soll denn die arme DB denn machen? Die TX ist kapott, die (dumme) Anwendung ignoriert dies aber und schickt weiter Befehle, als sei nix gewesen. Also wartet sie brav, bis ein ROLLBACK kommt (COMMIT geht auch, bewirk aber ein ROLLBACK). Von sich aus macht sie jedenfalls weder COMMIT (das machen andere Systeme wohl sporadisch ...) noch ROLLBACK.


    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
    Hannes23 ist offline Benutzer
    Registriert seit
    07.05.2010
    Beiträge
    39

    Standard

    @Andreas:

    Zitat Zitat von akretschmer Beitrag anzeigen
    Was genau bekommt denn der PG-Server als SQL übergeben?
    Das SQL sollte eigentlich passen, ich hab es mir zumindest ausgeben lassen und mal direkt über den pgAdmin ausgeführt. Da hat es geklappt. Das Script läuft auch generell schon seit Monaten so, nur dieses Mal ist ein Fehler aufgetreten :-(


    @ads
    Zitat Zitat von ads Beitrag anzeigen
    Sicher musst du das. Woher soll die Datenbank sonst wissen, dass du deinen Fehler bemerkt hast?
    Ok. Jetzt ist mir nur noch nicht ganz klar, wie ich den Rollback in meinen Python-Code integrieren soll. Ich meine, wenn wir von PSQL-Scripten reden, hat man die Transaktionen etwa so:

    BEGINN
    SELECT fehler;
    ROLLBACK;
    END

    Aber ich schicke ja einfach per curs.execute ein sql an die Datenbank und habe weiter nichts mit BEGINN oder END definiert. Wäre dann alles innerhalb meines sql-Strings die Transaktion? Müsste ich dann im Except-Teil das Rollback setzen? Also so in der Art:

    Code:
    sql="SELECT blablabla ... "
    rollback_sql = "ROLLBACK()"
    
            
    try:
       curs.execute(sql)
       row = curs.fetchall()
    except:
       curs.execute(rollback_sql)
    Geändert von Hannes23 (13.07.2010 um 15:08 Uhr)

  10. #10
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.020

    Standard

    Sorry, ich programmiere kein Python. Dafür musst du die Dokumentation zu Rate ziehen.
    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

Seite 1 von 2 12 LetzteLetzte

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