Delphi 2010 und MySQL

[MrSpock]

Hallo,

welche Komponenten würden ihr mir mit Delphi 2010 Prof. für den Zugriff auf eine MySQL DB empfehlen?

[Bernhard Geyer]

Mein "Gefällt mir" ist bei den Kompos von DevArt

[DeddyH]

MyDAC soll dem Vernehmen nach sehr gut sein.

[MrSpock]

Gehen auch Komponenten, die standardmäßig dabei sind ?
Falls nicht, reicht die günstigste Version von MyDac?

[franktron]

Was willste den machen =
Wenn du nur kleinkram machen willst dann kannste auch Zeaos nehmen,
wenn es eine vernünftige Software wird dann nimm die Kombos von Devart (MyDac oder UniDac)

[JohannesK]

Wir arbeiten seit ein paar Jahren mit MyDac unter Delphi 7 und stellen jetzt unter Delphi 2010 um auf Unidac. Unsere Erfahrungen sind durchwegs gut. Der Grund für die Umstellung auf Unidac ist die grössere Flexibilität für die unterlegte Datenbank, der Austausch des Providers reicht um auch andere Datenbanken anzusprechen.

Gruss

Johannes

[Bernhard Geyer]

Bei MySQL sollte man nicht die GPL-Falle vergessen. Benötigst du libmysql.dll so must zu bei Closed-Source Lizenzen kaufen.
Die DevArt-Kompos benötigen keine libmysql.dll (wenn entsprechend konfiguriert).

[MrSpock]

Danke für den Hinweis. Ich werde dann bzgl. Konfiguration bestimmt nochmal auf dich zukommen.

Nochmal die Frage: Funktionieren auch DB Komponenten, die bei Delphi 2010 Prof bereits dabei sind?

[Bernhard Geyer]

Zitat:

Zitat von MrSpock (Beitrag 1142590)

Nochmal die Frage: Funktionieren auch DB Komponenten, die bei Delphi 2010 Prof bereits dabei sind?

Werden sie nur für eine Lokal installierte DB. Für eine Server ist die Funktionalität erst aber der nächst größeren Version freigeschaltet.

Das Problem bei den mitgelieferten Version ist das DBMS-Änderungen sehr lange benötigen bis sie mit der (über)nächsten Version von Delphi unterstützt werden. So hat es ziemlich lange gedauert bis das geänderte PW-Verfahren von MySQL 4 (?) unterstützt wurde. Bei 3th-Party-Kompos hat man sowas i.d.R. innerhalb 1 Monats.

[Bbommel]

Zitat:

Zitat von MrSpock (Beitrag 1142590)

Nochmal die Frage: Funktionieren auch DB Komponenten, die bei Delphi 2010 Prof bereits dabei sind?

Ich selbst habe nur D2009, daher erst mal die Rückfrage: Ist bei D2010 auch noch die verpöhnte BDE dabei? Damit habe ich bei älteren Projekten einen Zugriff via ODBC auf eine MySQL-Datenbank realisiert. Wahrscheinlich wird das auch mit der Kombination ADO (dbGo-Komponenten)->ODBC->MySQL gehen, aber das habe ich noch nie getestet. Für diese Art der Lösung muss aber auf jedem Client, der dein Programm nutzen soll, der ODBC-Treiber von MySQL installiert sein.

Die Programme laufen alle seit ein paar Jahren prinzipiell problemlos, aber es sind auch alles kleinere Projekte. Wahrscheinlich sollte man das heute so nicht mehr realisieren, was man hier in der DP so liest. Aber um deine Frage zu beantworetn, wollte ich schon noch erwähnen: Ja, prinzipiell kommt man auch mit der Professionel-Ausgabe von Delphi schon im Standard weiter.

[Bernhard Geyer]

Zitat:

Zitat von Bbommel (Beitrag 1142604)

Ich selbst habe nur D2009, daher erst mal die Rückfrage: Ist bei D2010 auch noch die verpöhnte BDE dabei? Damit habe ich bei älteren Projekten einen Zugriff via ODBC auf eine MySQL-Datenbank realisiert. Wahrscheinlich wird das auch mit der Kombination ADO (dbGo-Komponenten)->ODBC->MySQL gehen, aber das habe ich noch nie getestet. Für diese Art der Lösung muss aber auf jedem Client, der dein Programm nutzen soll, der ODBC-Treiber von MySQL installiert sein.

Bei beiden Zugriffsarten bist du in der GPL-Falle.

[Bbommel]

Mit GPL-Falle meinst du doch, dass ich Software in meinem Programm nutze, die unter der GPL steht, und damit mein Programm selbst auch unter die GPL stellen müsste, oder?

Trifft das denn zu, wenn ich das über ODBC mache? Mein Programm nutzt ja selbst überhaupt nichts von MySQL, sondern der ODBC-Treiber muss völlig unabhängig von meinem Programm installiert werden.

mal als Parallele gedacht: Wenn ich von Excel oder Access aus die Daten über diesen ODBC-Treiber aus der MySQL-Datenbank ziehe, dann ändert das ja auch nichts an der Lizenz von Excel oder Access.

Oder wo habe ich was übersehen?

[Bernhard Geyer]

Zitat:

Zitat von Bbommel (Beitrag 1142608)

Oder wo habe ich was übersehen?

Ja. MySQL/Sun/Oracle haben hier einen etwas eigene Definition von GPL.
Und die haben im Streitfall die besseren/teureren Anwälte.


Dein Programm läuft nicht ohne das der MySQL-ODBC-Treiber installiert ist -> GPL trifft zu.
Du kommst evtl. davon wenn du mehrer DBMS unterstützt und der User sein Ziel-DBMS selbst auswählen kann.

[Bbommel]

Danke für die Aufklärung. :)

[MrSpock]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1142545)

Bei MySQL sollte man nicht die GPL-Falle vergessen. Benötigst du libmysql.dll so must zu bei Closed-Source Lizenzen kaufen.
Die DevArt-Kompos benötigen keine libmysql.dll (wenn entsprechend konfiguriert).

Greifen die Zeos Komponenten über libmysql.dll auf MySQL zu?

[Bernhard Geyer]

Zitat:

Zitat von MrSpock (Beitrag 1142706)

Greifen die Zeos Komponenten über libmysql.dll auf MySQL zu?

Das letzte mal als ich sie getestet hatte haben sie das gemacht.

[MrSpock]

Hallo Bernhard,

wo steht das genau, dass man gegen die Lizenzbedingungen verstößt, wenn man über die libmysql.dll zugreift, aber nicht, wenn man diesen Connector nicht benutzt?

[Bernhard Geyer]

Zitat:

Zitat von MrSpock (Beitrag 1142708)

Hallo Bernhard,

wo steht das genau, dass man gegen die Lizenzbedingungen verstößt, wenn man über die libmysql.dll zugreift, aber nicht, wenn man diesen Connector nicht benutzt?

Wir hatten schon mal einen Vertriebsmitarbeiter von damals noch MySQL bei uns weil wir uns überlegt haben die embedded Version von MySQL einzusetzen.
Nachdem dort die Preise bei ca. 30 k€/a gelegen haben, wurde das verworfen. Um noch seine Weihnachtsprovision zu retten hat er seine letzte Trupfkarte gezogen und gemeint das wir doch eh schon über die libmysql.dll zugeifen und damit Lizenzpflichtig wären. Da wir aber die DevArt-Kompos einsetzen war das nicht der Fall und er hatte einen Dezembertermin ohne lukrative Provision abgehalten.

Auf die schnelle habe ich bezüglich libmysql.dll und GPL nur eine Buchauszug gefunden.

[Medium]

Zitat:

Zitat von MrSpock (Beitrag 1142708)

Hallo Bernhard,

wo steht das genau, dass man gegen die Lizenzbedingungen verstößt, wenn man über die libmysql.dll zugreift, aber nicht, wenn man diesen Connector nicht benutzt?

Es steht leider nirgends derart explizit, sondern muss mittels GPL, den Modifikationen dieser durch MySQL, und ein wenig Phantasie abgeleitet werden. Ich bin mir auch fast sicher, dass das Thema von Oracle recht bewusst eher obskur gehalten, oder zumindest nicht wahrgenommen wird. Fakt ist: Sobald man eine Anwendung hat, die die libmysql.dll zwingend und alternativlos voraussetzt, bist du definitiv angreifbar. Wir haben uns auch letztlich für die DevArt Lösung entschieden (UniDAC), vor allem weil das Interface dem von Zeos in den rudimentären Funktionen nahezu identisch ist, und wir unsere bestehenden Anwendungen (die in Unkenntnis über diese Unsicherheiten bei der MySQL-Lizenz entstanden sind) sehr einfach migrieren konnten. Das nette ist bei den DevArt Kompos einfach, dass sie eine vollständig native Lösung sind, die ohne jede Abhängigkeit daher kommt, und zudem die Durchreiche zur Auswahl der DB an den Anwender so einfach macht, dass einem Oracle in der bestehenden Lizenzvariante kaum durchsetzbar ans Bein pinkeln kann. Zumindest, so lange man MySQL nicht selbst mit ausliefert, sondern der Kunde diese DB aus freien Stücken wählt, und selbst einrichtet. (Natürlich auf Empfehlung und mit Support unsererseits...)

Das Kasus Knacktus ist, dass einfach die libmysql.dll auch unter der MySQL GPL steht, und dort das Linken allein als Lizenzübertragend/-wirksammachend interpretierbar ist. Es geht nichtmals um das DBMS selbst. Die DLL ist der Böse Bub. Sobald die aussen vor ist, ist man theoretisch immer sicher, da selbst auf MySQL geschneiderte Lösungen wie MyDAC noch immer MariaDB als Wahlmöglichkeit offen haben, was die letzte Finte in den Lizenzen von MySQL (Alternativlosigkeit) zumindest im Klagefall gut anfechtbar macht. Man muss nur aufpassen, wie man sein Produkt nachher verkauft. Du darfst eben nicht MySQL Installer/Sourcen/Binaries liefern, sondern maximal dem Kunden sagen: "Mit MySQL ginge es am besten, aber da wäre noch XXX und YYY und ..." - wenigstens im Papierkram.

Um zu obigen Erkenntnissen zu kommen, waren bestimmt 2 Tage Lektüre diverser Lizenztexte, Interpretationen, Fallbeispiele und Einschätzungen nötig. Oracle tut da wenig zur Klärung, auch in den eigenen Foren nicht. Ich habe zumindest noch nicht einen Fall gesehen, in dem ein UniDAC-benutzendes Programm dem Ersteller Probleme bereitet hätte - und ich habe echt viel und intensiv gesucht, da eine unternehmensweite Entscheidung daran hing. Live long and prosper.

[omata]

Die Diskussion finde ich sehr interessant und frage mich dabei: Warum eigentlich MySQL verwendet wird? Mit Firebird oder PostgreSQL hat man keinerlei Lizenz-Probleme, MySQL ist nun auch nicht sonderlich toll (gut seit kurzem kann man ja sogar Datenbank dazu sagen) aber warum kommt dieses Unkraut eigentlich so oft zum Einsatz? (Auf Webseiten verstehe ich das ja, weil es dort eben oft nur MySQL gibt, alerdings setzt sich dort auch immer mehr PostgreSQL durch)

[Bernhard Geyer]

Zitat:

Zitat von Medium (Beitrag 1142821)

Ich bin mir auch fast sicher, dass das Thema von Oracle recht bewusst eher obskur gehalten, oder zumindest nicht wahrgenommen wird.

Hier hat Oracle eigentlich nur die "Firmenpolitik" von Sun/MySQL übernommen.

Zitat:

Zitat von Medium (Beitrag 1142821)

Es geht nichtmals um das DBMS selbst.

Das habe ich auch schon anders gehört. Wenn dein Programm nur MySQL unterstützt und ohne eine solche DB nicht lauffähig ist und Closed Source ist, dann ist auch eine Lizenz nötig.

Zitat:

Zitat von Medium (Beitrag 1142821)

Ich habe zumindest noch nicht einen Fall gesehen, in dem ein UniDAC-benutzendes Programm dem Ersteller Probleme bereitet hätte

Solange der Entwickler bei UniDac nicht nur MySQL unterstützt haben sie da auch keine Handhabe.

[Medium]

Das ist ja das nette dabei: Da MariaDB (vom ursprünglichen Entwickler von MySQL, vom letzten noch komplett freien Stand geforktes DBMS) nahezu komplett kompatibel zu MySQL ist, trifft die Alternativlosigkeit praktisch nie zu, es sei denn, man verkauft ein Bundle. Falls das gestern nicht klar genug raus kam: Ja, es gibt zwei Klinken.
1) Linken der unter der MySQL GPL stehenden DLL
2) Das Programm läuft nur mit MySQL
Das zweite Zitat war so zu verstehen, dass Benutzung des DBMS allein, kein Problem ist. Das "Womit" und "Wen noch" sind wichtig.

Eliminiert man diese beiden Dinge, hat man ein schönes, reifes, komfortables freies DBMS für den professionellen Einsatz.

[Bernhard Geyer]

Zitat:

Zitat von Medium (Beitrag 1142843)

Eliminiert man diese beiden Dinge, hat man ein schönes, reifes, komfortables freies DBMS für den professionellen Einsatz.

Mittlerweile sehe ich (nachdem wir in der Firma den Kunden die freie Wahl geben) des öfteren den Einsatz des MS SQL Server Express 2008 R2.
Für viele Einsatzfälle ist 10GB DB-Größe ausreichend und wenn man mal dahinkommt wird vermutlich oft die überlegung sein ob man nicht doch ein paar € ausgibt. Die Daten sind ja (i.d.R.) viel mehr Wert als ein paar € für die DB.
Ein anderer Grund wird sein das viele sich einfach kein (weiteres) Oracle ins Haus holen wollen. Hatten schon öfter den Fall das ein große Oracle-DB im Haus war aber der Kunde trotzdem einen MS SQL Server aufgesetzt hat.

[DeddyH]

Zitat:

Zitat von omata (Beitrag 1142825)

Warum eigentlich MySQL verwendet wird? Mit Firebird oder PostgreSQL hat man keinerlei Lizenz-Probleme, MySQL ist nun auch nicht sonderlich toll (gut seit kurzem kann man ja sogar Datenbank dazu sagen) aber warum kommt dieses Unkraut eigentlich so oft zum Einsatz? (Auf Webseiten verstehe ich das ja, weil es dort eben oft nur MySQL gibt...

Endlich spricht mal jemand aus, was ich schon lange denke :thumb:

[Bbommel]

Warum noch immer so oft MySQL eingesetzt wird, wird wohl auch heute noch so ähnlich sein, wie es bei mir damals war, als ich damit was gebastelt hatte: Wenn man schon mal irgendwelche Web-Projekte hatte, dann kennt man MySQL einfach. Man weiß, dass man es einfach mal eben so runterladen und installieren kann. Man glaubt - fälschlicherweise - dass das ja Open Source und total kostenlos ist.

So war es vor einigen Jahren, aber ich schätze mal, dass sich durch die hohe Verbreitung von MySQL im Web daran bis heute nichts geändert hat.

Ich selbst setze mittlerweile auch auf den MS SQL Sever bzw. ist der beim Kunden schon vorhanden. Ist gut in Windows integriert, der Zugriff von Delphi klappt problemlos und sogar die Admin-Tools sind nicht schlecht, wenn man sich mal dran gewöhnt hat.

[MrSpock]

Zitat:

Zitat von DeddyH (Beitrag 1142890)

Zitat:

Zitat von omata (Beitrag 1142825)

Warum eigentlich MySQL verwendet wird? Mit Firebird oder PostgreSQL hat man keinerlei Lizenz-Probleme, MySQL ist nun auch nicht sonderlich toll (gut seit kurzem kann man ja sogar Datenbank dazu sagen) aber warum kommt dieses Unkraut eigentlich so oft zum Einsatz? (Auf Webseiten verstehe ich das ja, weil es dort eben oft nur MySQL gibt...

Endlich spricht mal jemand aus, was ich schon lange denke :thumb:

Ich bin ja selbst ein großer Firebird Fan. Einer der Kunden, für den ich ein Programm geschrieben hat, welchen auf der SAGE CL beruht, hat jetzt auf SNC (SAGE New Classic Line) umgestellt. Diese benutzt MySQL. Ich soll mein Programm jetzt so anpassen, dass es mit dem MySQL Server spricht. Jetzt weiß ich natürlich nicht, mit welchen "Rechten" SAGE MySQL Datenbanken nutzt. :?

[MrSpock]

Habe mich jetzt mal ein bisschen in die SNC eingelesen. Zunächst hat SAGE von MySQL DB lizenziert, so dass der Nutzer meines Programms bereits Lizenzgebühren als Teil des SAGE Pakets bezahlt. Außerdem sollen externe Programme über eine SAGE spezifische ODBC Schnittstelle auf die Daten zugreifen. Insbesondere auch schreibende Zugriffe. So bleibe die Konsistenz der DB gewährleistet. Damit brauche ich also keine zusätzlichen Komponenten :-)

[Medium]

:thumb: Damit bist du dann ja völlig und ganz aus dem Schneider :)

[Bernhard Geyer]

Zitat:

Zitat von MrSpock (Beitrag 1142902)

... Außerdem sollen externe Programme über eine SAGE spezifische ODBC Schnittstelle auf die Daten zugreifen. ...

Damit ist alles geklärt. Du greifst auf SAGE zu und nicht auf MySQL.