Hallo zusammen!
Ich versuche seit Wochen, auf einem Win32/MinGW-System eine QT-Anwendung mit einem MySQL-Embedded-Server zum Laufen zu bringen... bisher ohne Erfolg.
Zu dem Thema gibt es unzählige Threads in verschiedensten QT- und MySQL-Foren, die aber alle entweder vom Typ "Bis hier geht's, und dann komm' ich nicht weiter." oder "Theoretisch geht das so, aber ausprobiert hab ich's noch nicht" sind.
Mir ist kein einziger Fall bekannt, wo am Ende "Danke - Jetzt läuft's!" gestanden wäre, und langsam beginne ich ensthaft an der Machbarkeit meines Projektchens zu zweifeln.
Bevor ich jetzt mit Details zu meiner Entwicklungsumgebung (Eclipse) aufwarte, würde ich einfach gern wissen:
Ist da draußen irgend jemand, der schon einmal eine Win32-Applikation mit QT und MySQL-Embedded in einer MinGW-Umgebung kompiliert und zum Laufen gebracht hat?
Bin schon gespannt...
Schöne Grüße!
QT Win32/MinGW + MySQL Embedded... Alles nur ein Mythos?
Ohne mich jetzt überhaupt mit dem Thema "Embedded MySQL" auseinandergesetzt zu haben (benutze lieber echte[tm] Datenbanksysteme wie PostgreSQL), würd ich mal behaupten, daß dafür besondere Schnittstellen/Libraries vonnöten sind und du daher deinen eigenen QSqlDriver schreiben musst. Aber ich kann mich irren!
HTH && Gruß,
/dev
HTH && Gruß,
/dev
zu "echtes Datenbanksystem": Was immer du damit mit "echt" meinst... Ich würde MySQL schon als vollwertiges RDBMS einstufen. Die Embedded-Variante funktioniert zwar nicht über TCP/IP (sondern direkt übers API) aber deshalb ist sie noch lange nicht "unecht".Deever hat geschrieben:Ohne mich jetzt überhaupt mit dem Thema "Embedded MySQL" auseinandergesetzt zu haben (benutze lieber echte[tm] Datenbanksysteme wie PostgreSQL), würd ich mal behaupten, daß dafür besondere Schnittstellen/Libraries vonnöten sind und du daher deinen eigenen QSqlDriver schreiben musst. Aber ich kann mich irren!
HTH && Gruß,
/dev
zu "besondere Schnittstellen vonnöten": Sollte laut http://doc.trolltech.com/4.3/sql-driver ... sql-server eigentlich nicht der Fall sein.
Und bevor jetzt die nächste (allgemeine) Antwort kommt, dass unter obigem Link ja eh alles beschrieben sei, hier nochmal meine (ganz konkrete) Frage: Hat das schon jemand umsetzen können?
Gruß
Vielleicht habe ich es ja übersehen, aber ich denke, dass nirgends ein entsprechender Hinweis gegeben wird. Ganz im Gegenteil: in den FAQ und der BBCode-Dokumentation werden die Möglichkeiten verschiedener Formatierungen sogar ausdrücklich beschrieben.upsala hat geschrieben:1. Auch wenn es die Foren-Software ermöglicht, sollte man die Schriftgröße nicht nach belieben vergrößern.
Wenn eine Funktion nicht nur aktiviert, sondern auch ausdrücklich dokumentiert ist, sollte man sich wirklich nicht wundern, wenn diese von den Benutzern auch verwendet wird...
Danke für den Hinweis, aber ich weiß schon, was ich brauche.upsala hat geschrieben:2. Wenn du noch am Anfang deines Projektes stehst, dann solltest du dir wirklich mal Postgres zu Gemüte führen.
Möchte sonst noch irgendwer seine Oberlehrer-Ambitionen ausleben, oder gibts auch Leute, die auf meine Frage eingehen möchten?
Gib den restlichen 99.9% (die noch nie mit embedded mysql / mingw arbeiten mussten) ne Chance! Erzähl was... ! Woher hast du die libmysqld.dll (selbstgestrickt, aus binary-package)... Hast du Probleme zur Laufzeit oder scheitert das Ganze schon beim Compilen/Linken?bisher ohne Erfolg.
Weil wir noch immer keine Kristallkugel besitzen sind wir auf (Konsolen-)Fehlermeldungen angewiesen..
Und trotzdem noch mal allgemein gefragt und aus eigenem Intresse .... wozu ?
Ich mein embedded mysql und SQLite stehen irgendwie in direkter konkurrenz.
Wenn du über die QT schiene faehrst, gehen die meisten besonderheiten eines DB Systems soweiso verloren, durch die Abstraktion.
embedded mysql wuerde IMHO nur dann sinn machen, wenn du auf auf backups von "richtigen" Mysqldatenbanken zurueckgreifen willst. weiss ned ob amn die da direkt einspuelen kann ....
Procedures kannst eh da ned verwenden ....
Warum muss es unbedingt embedded mysql sein ?
Ciao ...
Ich mein embedded mysql und SQLite stehen irgendwie in direkter konkurrenz.
Wenn du über die QT schiene faehrst, gehen die meisten besonderheiten eines DB Systems soweiso verloren, durch die Abstraktion.
embedded mysql wuerde IMHO nur dann sinn machen, wenn du auf auf backups von "richtigen" Mysqldatenbanken zurueckgreifen willst. weiss ned ob amn die da direkt einspuelen kann ....
Procedures kannst eh da ned verwenden ....
Warum muss es unbedingt embedded mysql sein ?
Ciao ...
@solarix:
Habe schon vieles probiert. Meine jüngsten Versuche sind im wesentlichen analog zur Beschreibung unter http://www.jiggerjuice.net/software/qt-sql-drivers.html.
Die DLL kommt aus der MySQL-Distribution, wobei ich sowohl 4.1er- wie auch 5.1er-Versionen ausprobiert habe. Die DLLs müssen mit reimp und dlltool für die Verwendung in GNU-Umgebungen präpariert werden. Dann muss QT neu kompiliert werden, wobei die DLLs statisch gelinkt werden müssen. Weder beim kompilieren noch beim Linken gibts ein Problem. Eine kleine QT-Applikation zum Testen, kann dann ebenfalls ohne Troubles kompiliert und gestartet werden. Sobald aber ein Objekt vom Typ QSqlDatabase erstellt wird, crasht das Programm.
Gestern ist mir dann der Kommentar "note that it will crash if you don't statically link to the mysql/e library!" aus der qsql_mysql.cpp nochmal in den Sinn gekommen. Also habe ich (erstmals) gecheckt, ob QT (und damit die Applikation) tatsächlich statisch gegen MySQL gelinkt ist - und siehe da: die libmysqld.dll wird noch immer benötigt.
Gebaut habe ich QT mit folgenden Kommandos:
# mingw32-make clean
# configure -debug-and-release -static -qt-sql-mysql -l mysqld -I C:\MySQL\4.1.22\include -L C:\MySQL\4.1.22\embedded\dll\release
# mingw32-make sub-src
@RHBaum:
Meine Hauptmotivation für MySQL liegt darin, dass wir eine Anwendung entwickeln, die gleichzeitig auf einen lokalen Datenstand und auf einen (identisch strukturierten) Datenstand im Netzwerk zurückgreifen soll. Dabei soll das gleiche DBMS verwendet werden, damit identische Operationen auch sicher zu identischen Ergebnissen führen. Aber vielleicht hast du recht, und es ist alles nicht der Mühe Wert...
Schöne Grüße
Habe schon vieles probiert. Meine jüngsten Versuche sind im wesentlichen analog zur Beschreibung unter http://www.jiggerjuice.net/software/qt-sql-drivers.html.
Die DLL kommt aus der MySQL-Distribution, wobei ich sowohl 4.1er- wie auch 5.1er-Versionen ausprobiert habe. Die DLLs müssen mit reimp und dlltool für die Verwendung in GNU-Umgebungen präpariert werden. Dann muss QT neu kompiliert werden, wobei die DLLs statisch gelinkt werden müssen. Weder beim kompilieren noch beim Linken gibts ein Problem. Eine kleine QT-Applikation zum Testen, kann dann ebenfalls ohne Troubles kompiliert und gestartet werden. Sobald aber ein Objekt vom Typ QSqlDatabase erstellt wird, crasht das Programm.
Gestern ist mir dann der Kommentar "note that it will crash if you don't statically link to the mysql/e library!" aus der qsql_mysql.cpp nochmal in den Sinn gekommen. Also habe ich (erstmals) gecheckt, ob QT (und damit die Applikation) tatsächlich statisch gegen MySQL gelinkt ist - und siehe da: die libmysqld.dll wird noch immer benötigt.
Gebaut habe ich QT mit folgenden Kommandos:
# mingw32-make clean
# configure -debug-and-release -static -qt-sql-mysql -l mysqld -I C:\MySQL\4.1.22\include -L C:\MySQL\4.1.22\embedded\dll\release
# mingw32-make sub-src
@RHBaum:
Meine Hauptmotivation für MySQL liegt darin, dass wir eine Anwendung entwickeln, die gleichzeitig auf einen lokalen Datenstand und auf einen (identisch strukturierten) Datenstand im Netzwerk zurückgreifen soll. Dabei soll das gleiche DBMS verwendet werden, damit identische Operationen auch sicher zu identischen Ergebnissen führen. Aber vielleicht hast du recht, und es ist alles nicht der Mühe Wert...
Schöne Grüße
-
Christian81
- Beiträge: 7319
- Registriert: 26. August 2004 14:11
- Wohnort: Bremen
- Kontaktdaten:
Lustig dieses Halbwissen 
Eine Shared lib kann man nicht in eine static lib umwandeln. Deshalb ist der Kommentar 'note that it will crash if you don't statically link to the mysql/e library!' irgendwie... sinnlos. Und wenn ich Qt statisch baue dann hilft das auch gar nichts.
mit reimp wird ne import-lib erstellt damit man gegen die funktionen der shared lib linken kann, nichts mehr.
Hat natürlich nichts mit deinem Problem zu tun, aber man sollte sich schon ein wenig auskennen bevor man rumnörgelt
Einen Crash löst man am besten indem man mal einen Debugger bemüht und nachschaut.
Eine Shared lib kann man nicht in eine static lib umwandeln. Deshalb ist der Kommentar 'note that it will crash if you don't statically link to the mysql/e library!' irgendwie... sinnlos. Und wenn ich Qt statisch baue dann hilft das auch gar nichts.
mit reimp wird ne import-lib erstellt damit man gegen die funktionen der shared lib linken kann, nichts mehr.
Hat natürlich nichts mit deinem Problem zu tun, aber man sollte sich schon ein wenig auskennen bevor man rumnörgelt
Einen Crash löst man am besten indem man mal einen Debugger bemüht und nachschaut.
MfG Christian
'Funktioniert nicht' ist keine Fehlerbeschreibung
'Funktioniert nicht' ist keine Fehlerbeschreibung
Mit "echt" meinte ich an Postgres (oder eigentlich an !MySQL) nicht die Netzwerkunterstützung, sondern den Umfang an SQL-Möglichkeiten. Selbst SQLite ist für mich also "echter" als MySQL, das IMHO auch eher als Strafe denn als Datenbank anzusehen ist...edes hat geschrieben:Die Embedded-Variante funktioniert zwar nicht über TCP/IP (sondern direkt übers API) aber deshalb ist sie noch lange nicht "unecht".
Überleg dir, ob du MySQL auch lokal nicht einfach als Server laufen lassen willst. Ich kann mich wirklich nicht daran erinnern, auch nur einmal bisher davon gehört zu haben, daß das jemand "embedded" eingesetzt hätte. Und sonst: Firebird ist u.a. genau dafür gemacht, sowohl "embedded" als auch als Server zu laufen.Meine Hauptmotivation für MySQL liegt darin, dass wir eine Anwendung entwickeln, die gleichzeitig auf einen lokalen Datenstand und auf einen (identisch strukturierten) Datenstand im Netzwerk zurückgreifen soll. Dabei soll das gleiche DBMS verwendet werden
Um als shared lib vorhandenen Code statisch zu linken, muß natürlich stattdessen zuerst eine statische Library gebaut werden, klar. Aber ich kann in obiger Aussage beim besten Willen nicht erkennen, daß dem explizit wiedersprochen wird, wieso also Halbwissen?Christian81 hat geschrieben:Lustig dieses Halbwissen
Eine Shared lib kann man nicht in eine static lib umwandeln. Deshalb ist der Kommentar 'note that it will crash if you don't statically link to the mysql/e library!' irgendwie... sinnlos.
Oder indem man gleich ganz auf C++ verzichtet und stattdessen Python nimmt! *duck*Einen Crash löst man am besten indem man mal einen Debugger bemüht und nachschaut.
Gruß,
/dev
-
Christian81
- Beiträge: 7319
- Registriert: 26. August 2004 14:11
- Wohnort: Bremen
- Kontaktdaten:
Nunja - entweder Deine eine Doku ist falsch oder die obige Aussage - sie widersprechen sich total. Falls dies in ein und denselben Dokument steht ist es schlicht Unsinn.Deever hat geschrieben:Um als shared lib vorhandenen Code statisch zu linken, muß natürlich stattdessen zuerst eine statische Library gebaut werden, klar. Aber ich kann in obiger Aussage beim besten Willen nicht erkennen, daß dem explizit wiedersprochen wird, wieso also Halbwissen?Christian81 hat geschrieben:Lustig dieses Halbwissen
Eine Shared lib kann man nicht in eine static lib umwandeln. Deshalb ist der Kommentar 'note that it will crash if you don't statically link to the mysql/e library!' irgendwie... sinnlos.
Und dann hast Du vresucht Qt statisch zu bauen und gegen eine dynamische sql-lib gelinkt und gewundert warum immer noch die sql-lib benötigt wird.
Da gibts keine Crashes sondern gleich Backtraces, hast recht...Oder indem man gleich ganz auf C++ verzichtet und stattdessen Python nimmt! *duck*Einen Crash löst man am besten indem man mal einen Debugger bemüht und nachschaut.
Aber das hilft wohl alles nicht weiter. Kann Dir aber auch nicht wirklich helfen da ich keine Zeit habe das mal kurz durchzukompilieren.
Ich würde mal versuchen es mit MSVC zuu kompilieren - da fällt der reimp Schritt weg und Du siehst ob es dann geht (wovon ich ausgehe, auch mit MinGW)
MfG Christian
'Funktioniert nicht' ist keine Fehlerbeschreibung
'Funktioniert nicht' ist keine Fehlerbeschreibung
Ja, wesentlich intuitiver und zeitsparender, finde ich...Christian81 hat geschrieben:Da gibts keine Crashes sondern gleich Backtraces, hast recht...Deever hat geschrieben:Oder indem man gleich ganz auf C++ verzichtet und stattdessen Python nimmt! *duck*
Ich nicht, aber ich bin auch nicht der OP und verwende ohnehin kein Windous, nur Unix/Linux/OSX!Kann Dir aber auch nicht wirklich helfen da ich keine Zeit habe das mal kurz durchzukompilieren.
Ich würde mal versuchen es mit MSVC zuu kompilieren
Gruß,
/dev
@edes
- sql ist definiert, also muessten auf abstrakter ebene bei gleichen statements immer identische ergebnisse rauskommen ... wenn man gescheit sondertypen (Datum, uhrzeit etc) abstrahiert.
- die unterschiede die es dann noch geben koennte (Fehlerhaft, oder zeitkritisch / zugriffskritisch ) liegen dann meist an konzeptionellen dingen. und grad da ist embedded sql und das normale Mysql RDBMS ned zu vergleichen ....
embedded sql unterstuetzt nur nen subset der funktionen von mysql
bei embedded hat man immer exklusivzugriff ... multiuser probleme, transaktionen etc fallen da eh raus, was was man bei nem richtigen RDBMS ned unbeachtet lassen sollte ....
Also haettest du nur einen vorteil ... das du den gleichen SQL dialekt verwenden koenntest ...
Das seh ich wieder als nachteil, ich waer eher bestrebt, nur standardisierte sachen (SQL 92 etc.) zu benutzen ^^
Und, seid ihr fuer das RDBMS system mitverantwortlich ? Wenn nein ... dann ist es immer ne saugute idee, sich optionen offenzuhalten die meisten firmen haben Hausstandards, und trotz der Oracle Prognosen koemmen einem da immer ganz seltsame Dinge unter (firebird, mysql, Sybex produkte, MS SQL Server ) ....
Ciao ...
Genau das wuerd ich mir kritisch noch mal durchn kopf gehen lassen ...Dabei soll das gleiche DBMS verwendet werden, damit identische Operationen auch sicher zu identischen Ergebnissen führen. Aber vielleicht hast du recht, und es ist alles nicht der Mühe Wert...
- sql ist definiert, also muessten auf abstrakter ebene bei gleichen statements immer identische ergebnisse rauskommen ... wenn man gescheit sondertypen (Datum, uhrzeit etc) abstrahiert.
- die unterschiede die es dann noch geben koennte (Fehlerhaft, oder zeitkritisch / zugriffskritisch ) liegen dann meist an konzeptionellen dingen. und grad da ist embedded sql und das normale Mysql RDBMS ned zu vergleichen ....
embedded sql unterstuetzt nur nen subset der funktionen von mysql
bei embedded hat man immer exklusivzugriff ... multiuser probleme, transaktionen etc fallen da eh raus, was was man bei nem richtigen RDBMS ned unbeachtet lassen sollte ....
Also haettest du nur einen vorteil ... das du den gleichen SQL dialekt verwenden koenntest ...
Das seh ich wieder als nachteil, ich waer eher bestrebt, nur standardisierte sachen (SQL 92 etc.) zu benutzen ^^
Und, seid ihr fuer das RDBMS system mitverantwortlich ? Wenn nein ... dann ist es immer ne saugute idee, sich optionen offenzuhalten
die meisten firmen haben Hausstandards, und trotz der Oracle Prognosen koemmen einem da immer ganz seltsame Dinge unter (firebird, mysql, Sybex produkte, MS SQL Server ) .... Ciao ...