Zugriff auf MySQL

[idefix2]

In der DP gibt es ein älteres Tutorial von Chewie für den direkten Zugriff auf MySQL ohne Komponenten: http://www.delphipraxis.net/6543-mys...mponenten.html.

Der erste Link in dem Tutorial, von dem man die Pascal-Übersetzungen der MySQL C-Header herunterladen sollte, funktioniert leider nicht mehr.

Kann mir jemand sagen, ob diese Delphi Datei noch irgendwo verfügbar ist (oder eine andere Alternative)?

[Matze]

Evtl. ist es diese Datei (der durchgestrichene Link im Tutorial): http://www.audio-data.de/mysql.html
Die ist auch für Delphi 2010. Das Projekt scheint also noch gepflegt zu werden.

Wenn es die Datei ist, sag's mir bitte. Dann editiere ich den Link im Tutorial.

[idefix2]

Jaaaa, der Link ist es.

Danke.

[Matze]

Danke für deine Rückmeldung. Ich habe den Link angepasst.

[Schorschi5566]

Hallo Matthias,

Zitat:

Das Projekt scheint also noch gepflegt zu werden.

Na ja, oder so ähnlich. :-D

Delphi-Quellcode:

  function mysql_ssl_set(_mysql: PMYSQL; key, cert, ca, capath: PAnsiChar): longint; stdcall;

Die obige Deklaration ist jedenfalls genauso falsch, wie in der Version, die ich habe.

Da fehlt der Cipher. So ist's richtig:

Delphi-Quellcode:

  function mysql_ssl_set(_mysql: PMYSQL; key, cert, ca, capath, cipher: PAnsiChar): longint; stdcall;

Grüße,
Uwe

[himitsu]

Meine Deklaration/Header sind korrekt. (jedenfalls solange verwendeten die Dekumentationen von mysql.com diesbezüglich stimmen)

Nja, hab noch nicht alles verglichen, aber irgendwo gab es auch noch eine Differenz.

Was an dieser Datei aber "gut" ist, daß sie sich versucht an die Lib/DLL anzupassen ... meine Datei(en) ist/sind "fest" auf eine Lib/DLL-Version eingestellt (was ich aber nicht sooo als großen Nachteil seh, denn wenn man für MySQL 5.5 programmiert, wäre es eh nicht so gut, wenn man dann einfach eine 4.0er DLL unterschieben könnte, oder? ).

[Schorschi5566]

Hallo Himitsu,

Zitat:

Zitat von Himitsu

wäre es eh nicht so gut, wenn man dann einfach eine 4.0er DLL unterschieben könnte, oder?

Jedenfalls nicht, wenn's dann knallt. :-D

Ich finde die mysql.pas auch nicht schlecht aber der Zugriff war by DirectSQL "schöner". Zwei Klassen (TMySQLResult und TMySQLClient) und fertig. Ich habe mir dafür so eine Art Wrapper gebastelt, der den Zugriff wie bei DirectSQL macht aber mysql.pas nutzt.


Grüße,
Uwe

[himitsu]

Zitat:

Zitat von Schorschi5566 (Beitrag 1039156)

Jedenfalls nicht, wenn's dann knallt. :-D

Wenn dein Programm für 5.0 geschrieben ist (also Queries/Statements dafür verwendet, dann knallt es auch, wenn man ihm eine 4.1-DLL unterschiebt :zwinker:
Die Server sind hoffentlich abwärts kompatibel, so daß man falls dein Programm für 4.1 erstellt wurde dennoch mit einer 4.1-DLL (Client) auf 'nen 5.5er Server zugreifen kann, anstatt deinem Programm auch noch einen 5.5er Clienten unterzuschieben und zu hoffen, daß dieser auch läuft. PS: einige APIs wurden ja geändert und selbst wenn sich diese Unit anpaßt ... sie kennt nur das was sie kennt und es ist somit (aktuell) eh nicht möglich ihr z.B. 'nen 6.0-Clienten unterzuschieben.

Man muß also bei beiden Libs einen passenden Clienten verwenden (nur daß bei mir halt Weniger, bzw. nur Ausgewähltere passen)

Delphi-Quellcode:

TMySQLx       = ...;
TMySQL        = ^RMySQL;
TMyResult     = ^RMyResult;
TMyField      = ^RMyField;
TMyRow        = ^RMyRow;
TMyRows       = ^RMyRows;
TMyStatement  = ^RMyStatement;
TMyBinding    = ^RMyBinding;
TMyBindBuffer = ^RMyBindBuffer;

Nur 2 "Klassen" gingen bei mir nicht, da ich die Funktionen direkt in die, von ihnen für den Zugriff genutzten, Record integriert hab.

Delphi-Quellcode:

// statt
function mysql_ssl_set(_mysql: PMYSQL; key, cert, ca, capath, cipher: PAnsiChar): longint; stdcall;  
                    // ^^^^^^^^^^^^^^^

type
  // so
  TMySQL = ^RMySQL;
  RMySQL = record
    function mysql_ssl_set(key, cert, ca, capath, cipher: PAnsiChar): longint; stdcall;  
  end

  // wobei eigentlich ja so
  RMySQL = record
    function mysql_ssl_set(key, cert, ca, capath, cipher: AnsiString): longint; stdcall;  
  end;

Txxx ist also eigentlich ein Pxxx und das Rxxx ein Txxx
weiß noch nicht, ob ich das wieder ändere, aber ich dachte mir, daß Txxx (statt Pxxx) mehr an eine Klasse erinnert.
Aber da ich eh noch nicht weiß, was ich mit der Klasse TMySQLx (die statischen Funktionen, welche mal in RMySQL drin waren) mach, könnte es wohl doch so sein, daß ich es noch tausche und die statischen Funktionen wieder in den anderen Record verschiebe. :gruebel:



In deinem Fall sind also auch nur TMySQL, TMyResult und TMyRow, welche du benötigst,
bzw. zusätzlich noch TMyStatement und TMyBinding für die prepared Statements.

[Schorschi5566]

Hallo Himitsu,

kann gut sein, dass mein Wrapper nicht gerade vollständig ist.

In 95% aller Fälle brauche ich sowas:

Delphi-Quellcode:

unit Unit1;

interface

uses
  MySQL;

implementation

procedure Test;
var
  bEx, bUseSSL: Boolean;
  sqlClient : TMySQLClient;
  sqlResult : TMySQLResult;
  sName : String;
  iPort, iNumber : Integer;

begin
  sqlClient := TMysqlClient.Create;
  iPort := 3306;
  bUseSSL := True;
  bEx := sqlClient.connect_db('DB', 'User', 'Passwort', 'Host', iPort, bUseSSL);
  if bEx then
  begin
    sqlResult := sqlClient.query('SELECT * FROM TEST WHERE X > 5', True, bEx);
    if bEx then
    begin
      with sqlResult do
      begin
        First;
        while not Eof do
        begin
          sName := FieldByName('Name').AsString;
          iNumber := FieldByName('Number').AsInteger;
          Next;
        end;
        Free;
      end;
    end;
    sqlClient.disconnect_db;
    sqlClient.Free;
  end;
end;

end.

Das funktioniert soweit und ich muss mich nicht weiter um das ganze "Außenrum" der mysql.pas kümmern. ;)

TMyRow brauche ich nur intern. Nach "außen" sind es wirklich nur 2 Klassen.

Mit FieldByIndex, FieldByName, FieldValueByName konnte ich bisher alle Fälle abdecken.

Mit TMyBinding und TMyStatement habe ich bis jetzt noch nichts gemacht. Wozu ist das? Stored Procedures?


Grüße,
Uwe

[himitsu]

drum hatte ich auch mal angefangen zu schauen, was bei dir noch fehlt/falsch ist, aber erstmal wollte ich das Problem finden, warum "beide" Codes nicht immer funktionieren (siehe der "Fehler" am Ende deines Threads).

Im Prinzip ist mein Code nur eine direkte Protierung der Header
(drum ist die MySQLHeader.pas auch nicht großartig aufgeräumt, um die nächsten Änderungen besser erkennen und einpflegen zu können)
und deines quasi schon eine kleine "Komponente" :stupid:, für einen komfortableren Zugriff.

[Schorschi5566]

Hallo Himitsu,

meinst Du diesen "Fehler"?

Delphi-Quellcode:

_mysql: PMYSQL;

Deklariert ist es doch aber so:

Zitat:

Zitat von MySQL Documentation

24.2.3.64. mysql_ssl_set()
int mysql_ssl_set(MYSQL *mysql, const char *key, const char *cert, const char *ca, const char *capath, const char *cipher)

Ich habe bis jetzt mysql.pas nur auf Sachen abgeklopft, die die Funktion behindern. Also sowas wie den fehlenden Parameter cipher.

Zitat:

Zitat von Himitsu

und deines quasi schon eine kleine "Komponente" , für einen komfortableren Zugriff.

Stimmt. :) Ich finde die mysql.pas ohne sowas recht "überladen" (was interessiert mich beim Coden mysql_init und das ganz Libgedöns?). Auch der Zugriff auf Felder ist grausam. Wer auf DB-Felder über den Index zugreift, muss einen guten Grund haben oder hat noch nie eine Tabelle erweitert. :lol:

Vielleicht können wir ja Deins und Meins "verheiraten". 8-)

Schön wäre ja auch die libmysql.dll irgendwie zu integrieren, damit man nicht immer dafür sorgen muss, dass sie (die Richtige!) da ist. Habe mal irgendwo gelesen, dass man eine DLL in 'ner RES verpacken kann und drauf zugreifen kann ohne sie auszupacken.

Vielleicht könnte man das dann ebenfalls für die Zertifikate bei SSL hinbekommen. Wäre nicht schlecht, wenn man wieder nur eine EXE hätte.


Grüße,
Uwe

[himitsu]

Zitat:

Zitat von Schorschi5566 (Beitrag 1039196)

Schön wäre ja auch die libmysql.dll irgendwie zu integrieren, damit man nicht immer dafür sorgen muss, dass sie (die Richtige!) da ist.

Wenn wir in C++ Programmieren würden, dann könnte man direkt den Embedded-Server oder nur einen Embedded-Clienten nutzen.

Die Quellcodes der MySQL-Server/Clienten sind ja offen, aber "leider" nur in C++ geschrieben,
drum lassen sie sich nur schwer direkt in unsere Delphiprogramme einkompilieren.
Praktisch das was in die DLL einkompiliert ist, ließe sich auch direkt in ein C++-Programm einkompilieren.

Zitat:

Zitat von Schorschi5566 (Beitrag 1039196)

Habe mal irgendwo gelesen, dass man eine DLL in 'ner RES verpacken kann und drauf zugreifen kann ohne sie auszupacken.

Nee, aber temporär auspacken und dann nutzen ginge.

Wobei es auch (ich glaub Assabat hatte da was ... leider vergessen, wie er aktuell in der DP heißt) womit man die DLL direkt aus einer Resource in den RAM laden konnte, anstatt sie temporär (nach C:\Temp und Co.) zu entpacken und von Windows laden zu lassen.

Die Embedded-DLL find ich aber auch geil, denn man benötigt nur diese DLL und der Server steckt da schon drinnen. (hab ihn aber leider noch nicht komplett zum Laufen bekommen :cry: )


PS: du kannst aber nicht alles aus unseren Libs direkt vergleichen, denn ich hab mir einige Freiheiten genommen.
z.B. steht an einigen Stellen statt LongInt ein LongBool, da der Integer auch nur 0 oder <>0 liefert und mir somit ein Boolean doch eindeutiger erschien.

[Schorschi5566]

Hallo Himitsu,

Zitat:

Zitat von Himitsu

womit man die DLL direkt aus einer Resource in den RAM laden konnte

Jepp, das meinte ich. Den Ansatz habe ich nur noch nicht weiterverfolgt weil mir nicht klar ist, ob dann die ganze Zeit die ganze Lib im Speicher rumhängt. Bei mysql.pas ist es ja so, dass er nur die Funktionen lädt, die auch benötigt werden.

Embedded Server ist bestimmt nicht schlecht für kleinere Projekte. Ist doch vom Prinzip her sowas wie sqLite, oder? Brauche ich jetzt weniger, wäre aber nice to have. ;)

Die Abwärtskompatibilität von mysql.pas finde ich etwas übertrieben.

Im Normalfall sorgt man doch selbst dafür, dass eine passende (also halbwegs aktuelle) Lib auf dem Zielsystem vorhanden ist. Lästig ist eben nur, dass man dafür sorgen muss. :)

Zitat:

Zitat von Himitsu

du kannst aber nicht alles aus unseren Libs direkt vergleichen, denn ich hab mir einige Freiheiten genommen

Ist doch völlig egal, wenn das Ergebnis sinnvoll ist und davon gehe ich mal aus.

Die libmysql.dll zu verwenden halte ich auch für richtig weil es einfach schwierig wäre mit den MySQL-Developern Schritt zu halten, wenn man die komplette Lib in Delphi abbilden würde. Dabei kommt dann leider sowas wie DirectSQL heraus. Klasse Lib, aber leider buggy und praktisch nicht mehr verwendbar.

Ich glaube, die meisten Delphi-User suchen nach einer einfach zu handhabenden MySQL-Unit. Ging mir ja ähnlich, als ich bei DirectSQL gelandet bin.

Also den Ansatz mit DLL von RES->RAM werde ich mir nochmal ansehen. Das würde den Umgang mit MySQL unter Delphi schon nochmal deutlich vereinfachen. Und ob ein "Komfort"-Wrapper dann mysql.pas oder MySQLHeader.pas verwendet hängt nur davon ab, welche Unit besser gepflegt wird. :P


Grüße,
Uwe

[Bernhard Geyer]

Zitat:

Zitat von Schorschi5566 (Beitrag 1039211)

Die libmysql.dll zu verwenden halte ich auch für richtig weil es einfach schwierig wäre mit den MySQL-Developern Schritt zu halten, wenn man die komplette Lib in Delphi abbilden würde. Dabei kommt dann leider sowas wie DirectSQL heraus. Klasse Lib, aber leider buggy und praktisch nicht mehr verwendbar.

Ein wichtiger Grund die libmysql.dll zu vermeiden ist die GPL-Falle von MySQL. Nur wenn man alles selbst macht und diese DLL nicht benötigt ist man aussen vor. Und so oft ändert sich das Kommunikationsprotokoll von MySQL auch nicht das man hier für jede Version anpassungen im Quellcode vornehmen will (außer man will Erweiterungen nutzen).

[mkinzler]

Deshalb würde ich, wenn es geht auf ein andersxDBMS setzen oder Die Kompos von DevArts nehmen, welche ohne den Client funktionieren

[himitsu]

Hab mir grade mal dieses DirektMySQL angesehn ...
- stimmt, mit 'nem 5.1er Server kommt das nicht zurecht
- wurde anscheinend auch schon 5 Jahre nicht mehr weiterentwickelt
- und die haben versucht einen eigenen Clienten zu schreiben

meine Idee wäre eher gewesen den Originalclienten irgendwie zu integrieren oder gleich den kompletten Server.
praktisch so wie das mit dem ZLib auch bemacht wurde:
- irgendwie den C++-Code in .obj kompilieren
- und dann in Delphi nur noch einzulinken

[himitsu]

Zitat:

Zitat von Schorschi5566 (Beitrag 1039211)

Jepp, das meinte ich. Den Ansatz habe ich nur noch nicht weiterverfolgt weil mir nicht klar ist, ob dann die ganze Zeit die ganze Lib im Speicher rumhängt. Bei mysql.pas ist es ja so, dass er nur die Funktionen lädt, die auch benötigt werden.

Nee, es wird die komplette DLL/EXE in den RAM gemappt (wie bei den MMFs / Memory Mapped Files, wobei Windows auch "ungenutzte" Teile auslagern kann)
GetProAdress liefert nur die Eintrittsadresse der gewünschten Funktion ... ob man sich nun diese Adresse holt oder nicht ist egal, der Code ist so oder so in den Arbeitsspeicher gemappt.
Dein MysqlVarArray ist also unnötig. (ich denke mal, du wolltes darüber sorgen, daß die Funktionen wieder entladen werden, wenn nicht mehr benötigt)

Zitat:

Zitat von Schorschi5566 (Beitrag 1039173)

Mit TMyBinding und TMyStatement habe ich bis jetzt noch nichts gemacht. Wozu ist das? Stored Procedures?

diese Prepared Statements hatte ich auch grade erst kennengelernt.
(über's mysqli vom PHP ... so oft nutze ich DBs noch garnicht, drum wollte ich mir es so ähnlich wie in PHP einrichten. Und darum macht sich MySQL auch gut, weil ich dann ja nur Einwas lernen muß :oops: )

Delphi-Quellcode:

mysqli.query('INSERT INTO test VALUES (''' + mysql_real_escape(param1) 
  + ''', ''' + mysql_real_escape(param2) + ''')');

Delphi-Quellcode:

stmt = mysqli.prepare('INSERT INTO test VALUES (?, ?)');
stmt.bind_params(param1, param2);

es geht darum, daß man Variablen an Parameter/Results binden kann

hier mal Anhand deines Beispieles:

Delphi-Quellcode:

var 
  Name: String;
  Number, X: Integer;

X := 5;  // hab das X nur als Beispiel für einen "prepared" Parameter eingefügt
sqlClient := TMysqlClient.Create('DB', 'User', 'Passwort', 'Host', 3306, true);
if Assigned(sqlClient) then
begin
  sqlStmt := sqlClient.prepare('SELECT Name, Number FROM TEST 
WHERE X > ?');
  sqlStmt.bind_param(X);  
  sqlStmt.bind_result(Name);
  sqlStmt.bind_result(Number);
  if sqlStmt.execute then
  begin
    sqlStmt.First;
    repeat
      sName := Name;
      iNumber := Number;
    until not sqlStmt.Next;
    sqlStmt.Free;
  end;
  sqlClient.Free;  // das disconnect könnte man im Free mit unterbringen
end;

http://php.net/manual/de/pdo.prepared-statements.php

Delphi-Quellcode:

.Create

+

Delphi-Quellcode:

if Assigned(sqlClient) then

läßt sich über einen speziellen/eigenen Constructor erreichen.

[Schorschi5566]

Hallo Bernhard,

Zitat:

Zitat von Bernhard

Ein wichtiger Grund die libmysql.dll zu vermeiden ist die GPL-Falle von MySQL. Nur wenn man alles selbst macht und diese DLL nicht benötigt ist man aussen vor.

Ich denke, dass ich mich diesbezüglich gleich in mehreren Grauzonen befinde. :-D

1. Entwickle ich freiberuflich für ein Ingenieurbüro Software, die nicht weiterveräußert wird. Da ich dort auf Stundenbasis arbeite und nicht nur Software schreibe, dürfte es nicht einfach sein, einen kommerziellen Nutzen zu beweisen. Na ja, eigentlich schon, ich sag' ja Grauzone.
2. Ist in der Firma schon ein MySQL-Community-Server installiert (über die Zeiterfassungssoftware), der dafür verwendet wird.

Soweit ich weiß, wurden auch für den Server keine Lizenzgebühren entrichtet aber ich würde mal aus dem Bauch vermuten, dass das im Streitfall eher ein Problem für den Entwickler der Zeiterfassungssoftware wäre.

@Himitsu:

Zitat:

Zitat von Himitsu

Dein MysqlVarArray ist also unnötig.

mysql.pas ist doch gar nicht von mir. :lol: Nehme ich doch nur um mit meinem Quasi-DirectSQL-Wrapper auf libmysql.dll zuzugreifen. Und DirectSQL ist auch nicht von mir. ;)

Das heißt aber, dass man den RES->RAM-Ansatz doch mal probieren sollte, oder?

Zitat:

Zitat von Himitsu

sqlClient.Free; // das disconnect könnte man im Free mit unterbringen

Nee, es können ja über die Clientinstanz nacheinander verschiedene DBs verwendet werden. Ich lasse die Connections nicht offen, da das bei 40 Mitarbeitern und 4-5 verschiedenen Anwendungen pro Mitarbeiter etwas zuviel für den Community-Server wäre. Also disconnect ständig und free nur beim Schließen der Anwendung.

@mkinzler:

Zitat:

Zitat von mkinzler

Die Kompos von DevArts nehmen, welche ohne den Client funktionieren

Das ist so "visuelles Zeug", oder? Mag ich nicht so gerne bei DB-Sachen, ist aber Geschmackssache.



Nochmal was zur Lizenzproblematik. Gibt es eigentlich Fälle in denen MySQL/Sun/Oracle Unternehmen erfolgreich verklagt hat, weil sie für den eigenen Gebrauch die kostenlosen Versionen von Server/Client benutzt haben? Habe ich jetzt noch nicht gehört, was natürlich kein Freibrief ist. Wobei es wohl schon hauptsächlich um die kommerzielle Nutzung einer Software geht.

Wer ein Closed-Source-Projekt auf Basis von MySQL kostenlos verbreitet, wird sicherlich kaum ein lizenzrechtliches Problem bekommen. GPL hin oder her. Ohne Streitwert sicherlich auch kein Verfahren obwohl damit die GPL natürlich eigentlich verletzt ist.

Was ist eigentlich mit den Myriaden MySQL-Servern auf Webservern, die kommerziell mit Closed-Source-Shopsystemen genutzt werden? :stupid:



Grüße,
Uwe

[Bernhard Geyer]

Zitat:

Zitat von Schorschi5566 (Beitrag 1039241)

Wer ein Closed-Source-Projekt auf Basis von MySQL kostenlos verbreitet, wird sicherlich kaum ein lizenzrechtliches Problem bekommen. GPL hin oder her. Ohne Streitwert sicherlich auch kein Verfahren obwohl damit die GPL natürlich eigentlich verletzt ist.

Streiwert gibt es schon. Für jede Verteilung verlangt MySQL/Sun/Oracle eine Serverlizenz. Und wenn du 1000 Verteilungen hast: 1000*400€ = 400.000 € Streitwert - auch wenn du keinen Cent verdient hast!

Zitat:

Zitat von Schorschi5566 (Beitrag 1039241)

Was ist eigentlich mit den Myriaden MySQL-Servern auf Webservern, die kommerziell mit Closed-Source-Shopsystemen genutzt werden? :stupid:

Provider wie 1&1 werden eine Firmen-Lizenz von MySQL besitzen: Preisrahmen ab ca. 50k€/a - also ein klacks für solch einen Provider.

[himitsu]

Im Prinzip muß doch nur der Code, wo dieser GPL-geschützte MySQL-Code einkompiliert wurde, offengelegt (OpenSource) sein?

Beim Apache, bzw bei den meist verwendenten PHPModulen ist dieses ja der Fall, selbst wenn man den Quellcode nicht direkt sieht (man kann ihn sich dennoch frei runterladen) und außerdem nutzt dieses meistens auch eine (eigene) libmysql.dll und der QuellCode der hier angesprochenden libmysql.dll ist auch frei verfügbar (es sei denn jemand erstellt seine eigene DLL, was auch möglich wäre)
Die in meinem anderem Thread zur Verfügung gestellten DLLs sind alle von mysql.com und wurden direkt mit den von ihnen zur Verfügung gestellten Quellcodes erstellt.

Also sollte es doch bezüglich der GPL kein Probleme geben? :gruebel:

Selbst dann nicht, wenn man diese DLL in den Resourcen der EXE mit ausliefert. (da sie A) austauschbar wären und B) ihr Quellcode dennoch frei verfügbar ist)

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1039245)

Also sollte es doch bezüglich der GPL kein Probleme geben? :gruebel:

Selbst dann nicht, wenn man diese DLL in den Resourcen der EXE mit ausliefert. (da sie A) austauschbar wären und B) ihr Quellcode dennoch frei verfügbar ist)

Normalerweise nicht. Aber so wie MySQL diese Lizenz auslegt oder für sich definiert ist selbst das Nicht-Mitliefern wenn dein Programm ohne MySQL-Anbindung nicht lauffähig ist eine "direkte Einkompilierung" im Sinne von GPL.

Hatten schon mal einen MySQL-Vertriebler hier als wir uns überlegt haben MySQL in der Embedded-Version zu verwenden. Nach sein Preisangebot (30 k€/a für Isam-Tabellen) zu teuer war wollte er seine Provision mit der "Sie liefern doch sicherlich die libmysql.dll mit?" Frage sichern. Aber glücklicherweise haben wir hier die Kompos von DevArt im Einsatz - War damit nix mit übbigen Weihnachtsgeschenk für seine Frau/Kinder :-)

[himitsu]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1039247)

"Sie liefern doch sicherlich die libmysql.dll mit?"

und was wäre, wenn ich dann sage: "nöö, die lädt sich der Endbenutzer selber runter" ?

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1039250)

und was wäre, wenn ich dann sage: "nöö, die lädt sich der Endbenutzer selber runter" ?

Wie geschrieben: Solange das Programm zwingen einen Zugriff auf Mysql über die libmysql.dll benötigt (ob nun mitgeliefert oder selbst herunter geladen) ist bei einem ClosedSource-Programm eine kostenpflichtige Lizenz nötig - Jedenfalls nach Auslegung von MySQL.

[himitsu]

Is ja blöd.

Aber bei OpenSource isses nicht so, selbst wenn MySQL für ein Funktionieren nötig ist?

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1039252)

Is ja blöd.

Aber bei OpenSource isses nicht so, selbst wenn MySQL für ein Funktionieren nötig ist?

Ja, bei OpenSource wird keine Lizenz nötig - Aber nicht jeder will aus seinem Programm OpenSource machen.

[Schorschi5566]

Hallo zusammen,

also nochmal zum Mitschreiben...

Der Server hat damit also prinzipiell nichts zu tun, wenn ich das richtig verstehe.

Also ein Closed-Source-Projekt welches nicht über libmysql.dll auf irgendeinen MySQL-Server zugreift ist legal. Wird ein Communityserver verwendet ist es also ok und kostenfrei.

Vielleicht sollte man sich dann doch überlegen ob man DirectSQL wiederbelebt. Die Version bis D6 hat einwandfrei funktioniert. Vermutlich wurde die Lib nur etwas unsauber auf D2010 gehievt.

Die C-Sourcen von libmysql.dll auf Delphi zu porten, dürfte ja genauso gegen die GPL verstossen.

Interessant wären natürlich wirklich ein paar deutsche Gerichtsurteile zu genau diesem Thema, denn eigentlich wird weder am Client noch am Server irgendetwas verändert. Kann gut sein, dass die Auslegung der GPL von MySQL hierzulande nur heiße Luft ist, aber wer will es schon darauf ankommen lassen. ;)

Außerdem kann man auch mit OpenSource-Projekten Geld verdienen. 8-) :P


Grüße,
Uwe

[xZise]

Moin,

Zitat:

Zitat von Schorschi5566 (Beitrag 1039241)

Zitat:

Zitat von Himitsu

sqlClient.Free; // das disconnect könnte man im Free mit unterbringen

Nee, es können ja über die Clientinstanz nacheinander verschiedene DBs verwendet werden. Ich lasse die Connections nicht offen, da das bei 40 Mitarbeitern und 4-5 verschiedenen Anwendungen pro Mitarbeiter etwas zuviel für den Community-Server wäre. Also disconnect ständig und free nur beim Schließen der Anwendung.

Dann speicherst du zwischen, ob du verbunden bist, und disconnectest dann, wenn es noch nötig ist.

MfG
Fabian

[Schorschi5566]

Hallo Fabian,

danke aber das passt schon so. :)


Grüße,
Uwe

[Bernhard Geyer]

Zitat:

Zitat von Schorschi5566 (Beitrag 1039314)

Also ein Closed-Source-Projekt welches nicht über libmysql.dll auf irgendeinen MySQL-Server zugreift ist legal. Wird ein Communityserver verwendet ist es also ok und kostenfrei.

Wenn du den Community-Server nicht mitlieferst.

Zitat:

Zitat von Schorschi5566 (Beitrag 1039314)

Vielleicht sollte man sich dann doch überlegen ob man DirectSQL wiederbelebt. Die Version bis D6 hat einwandfrei funktioniert. Vermutlich wurde die Lib nur etwas unsauber auf D2010 gehievt.

Gib lieber ein paar € für die DevArt-Kompos aus. Sind ihr Geld wert.

Zitat:

Zitat von Schorschi5566 (Beitrag 1039314)

Die C-Sourcen von libmysql.dll auf Delphi zu porten, dürfte ja genauso gegen die GPL verstossen.

Die Sourcen zu portieren vermutlich, jedoch nicht wenn du neu gegen das Netzwerkprotokoll implementierst.

Zitat:

Zitat von Schorschi5566 (Beitrag 1039314)

Interessant wären natürlich wirklich ein paar deutsche Gerichtsurteile zu genau diesem Thema, denn eigentlich wird weder am Client noch am Server irgendetwas verändert. Kann gut sein, dass die Auslegung der GPL von MySQL hierzulande nur heiße Luft ist, aber wer will es schon darauf ankommen lassen. ;)

Willst du es darauf ankommen lassen? Eine Lösung gibt es ab so 100/200€
Und vor allem wird mit sicherheit wenn du dein Programm auch außerhalb Deutschlands anbietest Wahrscheinlich eine Anklage an entsprechen Klägerfreundlichen Gerichtsstandorten in der USA erfolgen.

[Schorschi5566]

Hallo Bernhard,

es geht nicht nur um's Geld. Ich würde durchaus als Entwickler in ein DBMS investieren, wenn ich es anschließend frei verwenden darf. Keine 5-stelligen Beträge aber umsonst muss es nicht sein. Ich muss Embarcadero auch nicht jedesmal etwas bezahlen, wenn ich ein Delphiprogramm verkaufe.

Ich möchte eine vernünftige Lösung mit MySQL und ohne visuelle Komponenten. Und außerdem möchte ich nicht (gefühlte) 50 SQL-Projekte umschreiben. :-D

Der GPL-Exkurs war recht interessant, betrifft mich aber derzeit eher nicht, weil ich die Projekte weder verkaufe noch einer großen Community zugänglich mache (siehe oben).

Trotzdem ärgert mich so eine Lizenzpolitik, bei der man sich durch etliche Seiten lesen darf, bis man mal ansatzweise merkt ob man sich gerade noch in der Legalität befindet oder schon mit diversen Anwälten rechnen muss. ;)

Ich verstehe, dass MySQL auch Geld mit seinen Produkten verdienen muss aber eine weniger restriktive Lizenzgestaltung für kleine Projekte/Firmen würde ihnen sicherlich nicht schaden. Oder eine bessere Preisstaffelung.

Die Problematik ist schon alt und es war immer schon schwierig DBMS zu finden, die nicht tausende von Mark (ja, so alt ist die Problematik schon :lol:) pro ausgelieferter Version einer Software haben wollten.

Na ja, wenn Open Source die Hintertür ist, lädt man so ein Projekt halt auf einen beliebigen Webserver und sperrt die Suchmaschinen aus. Dann ist es auch Open Source oder haben sie da auch was in die GPL reingebastelt? ;)


Grüße,
Uwe

[mkinzler]

Btw: MySQL ist nicht das einzige (OpenSource) DBMS

[Schorschi5566]

Hallo Markus,

kannst Du was Vergleichbares empfehlen? Rein interessehalber. :)

MySQL wird, wie gesagt, schon bei meiner Arbeitsstelle eingesetzt und kann nicht ohne großen Aufwand ersetzt werden.


Grüße,
Uwe

[mkinzler]

FireBird, PosGresSql, ...
Von FireBird gibt es auch eine embedded Version, welche ohne Codeänderug ( nur Änderung des Connectionstrings) funktioniert.