Feststellen, ob noch Verbindung zur Datenbank besteht

Markus · Beitrag von **Markus** » 27. April 2010 14:16

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

kater · Beitrag von **kater** » 27. April 2010 16:03

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?

Markus · Beitrag von **Markus** » 27. April 2010 16:10

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.

Beitrag von **Christian81** » 27. April 2010 19:13

'ORA-03114' ändert sich nicht - das sind wie bei Informix und ggf. auch anderen fest definierte Texte

Markus · Beitrag von **Markus** » 28. April 2010 08:53

Okay, aber sehe ich das richtig, dass es sonst keine andere Möglichkeiten gibt, ob die DB-Verbindung noch korrekt ist, oder?

Troll.Soft · Beitrag von **Troll.Soft** » 28. April 2010 14:21

Du kannst den Typ der Fehlermeldung von lastError() abfragen. Dürfte sich kaum in naher Zukunft ändern und sollte bei unterschiedlichen Datenbanken gleich sein

Code: Alles auswählen

type()    QSqlError::StatementError()

tschüß
Troll.Soft

AuE · Beitrag von **AuE** » 29. April 2010 12:13

Das Problem ist doch das isOpen() true liefert..... wie kann man das Umgehen das ist doch hier die Frage!

Troll.Soft · Beitrag von **Troll.Soft** » 29. April 2010 18:02

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

AuE · Beitrag von **AuE** » 29. April 2010 18:16

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!

upsala · Beitrag von **upsala** » 29. April 2010 22:58

QSqlError liefert im übrigen nicht nur einen Text sondern auch eine Nummer.

Troll.Soft · Beitrag von **Troll.Soft** » 30. April 2010 08:10

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

Markus · Beitrag von **Markus** » 30. April 2010 09:54

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.

Markus · Beitrag von **Markus** » 30. April 2010 10:00

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.

AuE · Beitrag von **AuE** » 30. April 2010 11:24

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!