Zugriff auf MySQL

[Schorschi5566]

Hallo Himitsu,

meinst Du diesen "Fehler"?

_mysql: PMYSQL; Deklariert ist es doch aber so:

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 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.

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

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 von Schorschi5566:

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 von Schorschi5566:

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 )


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 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 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.


Grüße,
Uwe

[Bernhard Geyer]

Zitat von Schorschi5566:

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 von Schorschi5566:

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 von Schorschi5566:

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ß )

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


.Create + if Assigned(sqlClient) then läßt sich über einen speziellen/eigenen Constructor erreichen.

[Schorschi5566]

Hallo Bernhard,

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.

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 von Himitsu:

Dein MysqlVarArray ist also unnötig.

mysql.pas ist doch gar nicht von mir. 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 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 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?



Grüße,
Uwe

[Bernhard Geyer]

Zitat von Schorschi5566:

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 von Schorschi5566:

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

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?

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)