Seite 1 von 1
Feststellen, ob noch Verbindung zur Datenbank besteht
Verfasst: 27. April 2010 14:16
von Markus
Hallo zusammen!
Hat sich jemand schonmal mit dem o.g. Thema beschäftigt?
Wenn ich feststelle, dass eine QSqlQuery auf einen Fehler läuft, möchte ich gerne ermitteln, ob noch eine korrekte Verbindung zur entfernten Datenbank besteht. In meinem Fall Oracle und MySql.
Mein Testfall: Ich verbinde mich fehlerfrei zur Oracle-Datenbank und kann Selects ausführen. Dann ziehe ich das Netzwerkkabel von meinem Rechner. Die Funktion "QSqlQuery->exec()" beendet sich mit "false" und lastError() gibt folgende Infos, die mir leider nicht weiterhelfen:
Code: Alles auswählen
QSqlDatabase.isOpen() -- > true
QSqlDatabase.isOpenError() --> false
QSqlQuery.lastError()->type() --> 2 (QSqlError::StatementError)
QSqlQuery.lastError()->databaseText() --> "ORA-03114: Nicht mit ORACLE verbunden"
QSqlQuery.lastError()->driverText() --> Unable to execute select statement
Gehe ich falsch an die Sache ran oder ist es schwierig die abgebrochene Verbindung zu erkennen?
Viele Grüße,
Markus
Verfasst: 27. April 2010 16:03
von kater
Da steht:
QSqlQuery.lastError()->databaseText() --> "ORA-03114: Nicht mit ORACLE verbunden"
Siehst du das? Nicht verbunden -> keine korrekte Verbindung zur Datenbank.
Oder versteh ich das jetzt nicht?
Verfasst: 27. April 2010 16:10
von Markus
Ja, das steht da.
Nur ich will nicht den Text vergleichen, um herauszufinden, ob noch eine funktionierende Verbindung besteht. Denn der Text kann sich auch ändern (Englische Version, Client-Unterschiede,usw.)
Es ist halt ein Serverprogramm, dass automatisch einen Reconnect machen soll.
Es gibt keinen anderen Hinweis, dass keine Verbindung zur Datenbank besteht. QSqlDatabase->isOpen() liefert true zurück. Alles deutet auf eine korrekt DB-Verbindung hin, wohl es nicht so ist.
Verfasst: 27. April 2010 19:13
von Christian81
'ORA-03114' ändert sich nicht - das sind wie bei Informix und ggf. auch anderen fest definierte Texte
Verfasst: 28. April 2010 08:53
von Markus
Okay, aber sehe ich das richtig, dass es sonst keine andere Möglichkeiten gibt, ob die DB-Verbindung noch korrekt ist, oder?
Verfasst: 28. April 2010 14:21
von Troll.Soft
Du kannst den Typ der Fehlermeldung von lastError() abfragen. Dürfte sich kaum in naher Zukunft ändern und sollte bei unterschiedlichen Datenbanken gleich sein
tschüß
Troll.Soft
Verfasst: 29. April 2010 12:13
von AuE
Das Problem ist doch das isOpen() true liefert..... wie kann man das Umgehen das ist doch hier die Frage!
Verfasst: 29. April 2010 18:02
von Troll.Soft
AuE hat geschrieben:Das Problem ist doch das isOpen() true liefert..... wie kann man das Umgehen das ist doch hier die Frage!
nana,
die Antwort auf diese Frage hast Du anscheinend nicht erkannt.
1. Qt liefert Unsinn.
2. Also eigene Funktion bool isConnected() o.ä.
3. oder lastError() jedesmal auswerten
an AuE, falls Du eine Funktion von Qt kennst, die das macht, bitte mitteilen.
tschüß
Troll.Soft
Verfasst: 29. April 2010 18:16
von AuE
Das ist es ja grade ... das ist denke ich ein Bug/Feature von Qt
Und der ders gefunden hat darf den Bug eingeben
Was passiert denn wenn du einmal ne query abschießt (die ja dann schief geht) und anschließend nochmals ein isOpen() machst? Spätestens dann sollte dort false kommen.
Ich habe das früher so gelöst das ich meiner open Funktion nen bool bForce = false mitgegeben habe ... und dann einfach wenn ich nen fehler hatte die Funktion mit true aufgerufen habe. Spätestens da solte dann ja etwas passieren!
Verfasst: 29. April 2010 22:58
von upsala
QSqlError liefert im übrigen nicht nur einen Text sondern auch eine Nummer.
Verfasst: 30. April 2010 08:10
von Troll.Soft
upsala hat geschrieben:QSqlError liefert im übrigen nicht nur einen Text sondern auch eine Nummer.
hm hm, war das nicht weiter oben schon mein Tip.
AuE hat geschrieben:Das ist es ja grade ... das ist denke ich ein Bug/Feature von Qt
So sehe ich die Sache allerdings auch. Nur angesichts der sonstigen Qualität von Qt und der Tatsache, das Sql schon länger im Angebot von Qt ist kann ich mich des Eindrucks nicht erwehren das Qt diesen Unsinn für ein sinnvolles Feature hält.
QSqlIndex z.B. ist eine sinnfreie Klasse
tschüß
Troll.Soft
Verfasst: 30. April 2010 09:54
von Markus
Was mich bei dem Error-Type von lastError() verwundert ist, dass er bei einem Verbindungsproblem "StatementError" liefert, obwohl das SQL-Statement 100% in Ordnung ist.
Ich habe es jetzt so gelöst, dass ich bei fehlerhaften Ausführen von QSqlQuery->exec(), die Datenbankverbindung schließe, sie neu aufbaue und das Query noch einmal ausführe. Denn alle Statements werden von der Software generiert, so dass Syntaxfehler auszuschließen sind.
Nur ich muss Troll.Soft zu stimmen, dass das Handling von Verbindungsproblemen nicht "ganz korrekt" ist oder verbessert werden könnte.
Verfasst: 30. April 2010 10:00
von Markus
AuE hat geschrieben:Was passiert denn wenn du einmal ne query abschießt (die ja dann schief geht) und anschließend nochmals ein isOpen() machst? Spätestens dann sollte dort false kommen.
Meiner Erkenntnis nach liefert isOpen() immer "true" zurück bis man eigenhändig die Datenbank schließt. Will man dann die Datenbank wieder öffnen (was ja wegen Netzwerkprobleme - Kabel ab) nicht geht, wird es erkannt und isOpen() und isOpenError() liefern korrekte Return-Werte.
Verfasst: 30. April 2010 11:24
von AuE
Dann ist es ein Bug -> wenn dir die Query auf Grund von keiner Verbindung (Was ja der Error sagt) um die Ohren fliegt darf danach isOpen() nicht true liefern!