qtforum.de

Hallo, habe leider keine Ahnung von Proxies, muss mein Programm aber auf der Arbeit in der dortigen Umgebung (in nem virtuellen XP) zum Laufen bekommen. Unsere IT meint ich muss für die Verbindung zum MySQL-Server, obwohl er auf localhost läuft, einen Proxy angeben. Es ist im System einer definiert und sowohl MS Access (bzw. eher der MySQL-ODBC-Connector dazwischen) und Internetbrowser können auf localhost:3306 bzw. der Browser auf localhost:80 zugreifen. Mein Qt-Programm scheint diese Proxyinformationen nicht auszuwerten. Mit würde das dann vermutlich auch bei mir für

QAbstractSocket, QTcpSocket, QUdpSocket, QTcpServer, QNetworkAccessManager and QFtp

funktionieren, habe ich noch nicht probiert, aber zum MySQL-Server kann sich die QSqlDatabase nicht verbinden, für ihn gelten diese Einstellungen scheinbar nicht. Auf einem eigenen virtuellen XP ohne Proxynotwendigkeit und ähnlichem Setup funktioniert die Verbindung problemlos.

Kann ich irgendwie ein Proxy für die MySQL-Verbindung definieren? Oder meinem kompletten Programm irgendwie die Systemproxyeinstellungen einprügeln? Oder andere Vorschläge?

Danke
FaS

Die Datenbank-Plugins in Qt erfüllen nichts weiter als ein "Datenbank-Interface" für die Qt-Applikation. Von der Technologie hinter dem Plugin weiss Qt nichts... Im Fall von MySQL benutzt das Plugin eine Library von MySQL (libmysqlclient oder so), welche dann den tatsächlichen TCP/IP-Code implementiert hat. Daher: von deinen Proxy-Einstellungen kann die mysql-Library nun wirklich nichts wissen...

Aber: warum brauchst du einen Proxy? Der Server läuft auf dem localhost..oder? Der Client ebenfalls...? Du wirst den Server ja bereits getestet haben (z.B. mit dem Mysql-Query-Browser oder sonst einem MySQL-Client). Warum sollte also das Qt-Programm einen Proxy benötigen?

Ich weiß nicht, warum der einen Proxy benötigt, ich weiß nur, dass das Programm keine Verbindung herstellen kann. Im IE sind Proxyeinstellungen hinterlegt, ich nehme an andere Programme verwenden diese, weshalb Browser und Access damit klar kommen. Mir scheint das zwar für localhost auch unsinnig, aber ob das deswegen technisch nicht notwendig ist muss man daraus ja nicht unbedingt schließen.

Öffne doch einfach die Eingabeeinforderung und gib ein:

telnet localhost 3306

dann weißt du, ob es ohne Proxy funktioniert

telnet localhost 3306: Der HeidiSQL-Client kann sich mit der DB verbinden, weiß nicht ob das was zu bedeuten hat.. gibt es einen kostenlosen Client, wo man weiß, dass er keinen Proxy verwendet? Muss mal schauen ob ich den Fehler irgendwie besser identifizieren kann, bin nur leider nicht vor Ort.. ich weiß nur dass es auf einem ähnlichen Setup ohne Proxy funktioniert und weitere Parameter die eine Verbindung verhindern könnten fallen mir nicht ein.

Also: kein Proxy

Soweit so gut. Was liefert denn dein Qt-Programm für Fehler?

FaS hat geschrieben:telnet localhost 3306:

Code: Alles auswählen

J
 5.5.16T^gkb,R:☻ǧ}]8@wY9Pd*AImysql_native_password
 
Verbindung zu Host verloren.

Der HeidiSQL-Client kann sich mit der DB verbinden, weiß nicht ob das was zu bedeuten hat.. gibt es einen kostenlosen Client, wo man weiß, dass er keinen Proxy verwendet? Muss mal schauen ob ich den Fehler irgendwie besser identifizieren kann, bin nur leider nicht vor Ort.. ich weiß nur dass es auf einem ähnlichen Setup ohne Proxy funktioniert und weitere Parameter die eine Verbindung verhindern könnten fallen mir nicht ein.

Die Eingabeinforderung verwendet definitiv keinen Proxy, daher liegts wohl an der QT Anwendung, so wie solarix bereits sagte .

Minimalbeispiel?

Okay danke für die Infos, also nicht der Proxy.
Tatsächlich ist das Problem, dass der MySQL-Treiber nicht geladen wird. Das Plugin ist an der richtigen Stelle, das ODBC-Plugin daneben wird nämlich geladen und das ganze funktioniert ja auch auf einem Zweitsystem (lösche ich dort das mysql-Plugin, wird das auch dort nicht geladen). D.h. dieses Plugin (qsqlmysql4.dll) wird auf einem Test-System herangezogen und auf dem Ziel-System nicht. Kann es sein, dass es Abhängigkeiten hat, die nicht erfüllt werden?

Dependcy Walker ist (wie immer bei diesen Plugin-Problemen) dein Freund.

Starte deine Anwendung im Debug Modus, dann schreit QT auch, dass der Driver nicht geladen werden konnte...

DBGTMaster hat geschrieben:Starte deine Anwendung im Debug Modus, dann schreit QT auch, dass der Driver nicht geladen werden konnte...

Und was sollte ihm das helfen abgesehen davon dass er die Debug-Executables wohl gar nicht auf dem Zielrechner ausführen kann (Stichwort: MS Visual Studio Debug Runtime Libraries)?

Gracias, alle die mir geholfen haben! Die gedankliche Eliminierung der Proxy-Fokussierung war hier wohl am wichtigsten (thx DBGTMaster).
Schließlich hat libmysql.dll gefehlt (thx Christian81 und solarix, ich hätte deinen ersten Beitrag bewusster lesen sollen ). Ich war es von Windows gewohnt bei fehlenden DLLs eine Meldung zu bekommen, bei den Plugins ist das wohl nicht der Fall. Naja fehlende vc++ redist packages werden ja auch in keinster Weise angezeigt, das ist noch viel erstaunlicher..
Debug-Executables> Ich verwende MinGW, bräuchte man da auch son Unfug? Ein CONFIG += console hätte aber vermutlich auch gereicht.
Danke
FaS

Nein, bei MinGW gibts nicht so ein Problem, allerdings sind da die Debug-Libs massig groß
config += console hätte reichen müssen bzw. siehe http://doc.qt.nokia.com/latest/qtglobal ... MsgHandler + Logfile

Danke, das sollte ich wirklich mal einbauen in Zukunft..

Ich war es von Windows gewohnt bei fehlenden DLLs eine Meldung zu bekommen, bei den Plugins ist das wohl nicht der Fall.

Ist ne Frage des Pluginprinzips generell ...
Nen plugin ist immer optional, also nie zwingend.

Nun ist die Frage, wie soll sich ein Pluginmanager verhalten, der eine PluginDll anziehen will um festzustellen, ob das ueberhaupt nen plugin ist ... , diese Dll aber wegens ihren Abhaengigkeiten gar ned erst anziehen kann (loadlibrary fehler).
Das ist ne stelle, bevor er ueberhaupt erkennen kann, ob die Dll selber eigentlich nen plugin ist, oder irgend eine andere erweiterungsdll, die in dem verzeichniss liegen muss, damit andere plugins laufen ....
Wenn er da laut schreit, muesst er auch bei jeder dll schreien, die keine oder die falsche Version der Pluginschnittstelle bietet. Die User waeren recht schnell genervt.
Sowas kommt maximal ins logfile ...

Ciao ...