Kontakt gesucht - Der Entwickler - Das Magazin für professionelle IT-Lösungen

MySQL AB
Die Datenbank MySQL hat gerade in den vergangenen zwei Jahren eine rasante Weiterentwicklung erlebt. Die Entwickler bei MySQL AB, der Firma, die MySQL anbietet, stellen auf ihrer Webseite [1] mehrere Versionen der Datenbank parallel zum Download zur Verfügung. Hierbei ist meist eine Version aktuell, es finden größtenteils nur Bugfixes statt, und mindestens eine Version vom zukünftigen Release, damit man sich schon mit den neuen Features der nächsten Version vertraut machen kann. Nach der Freigabe des nächsten Releases wird das vorherige noch ein paar Monate unterstützt, bis die Entwicklung daran eingestellt wird. Während die Version 3.23.x über etwa 2,5 Jahre als so genanntes Production-Release geführt wurde, waren es bei der Version 4.0.x nur noch 1,5 Jahre. Die aktuelle Version 4.1 soll Gerüchten zufolge schon in diesem Jahr einen für die Produktion freigegebenen Nachfolger (5.0) erhalten. Die Versionszyklen werden also kürzer.
Wie es bei Datenbankprodukten häufig der Fall ist, wird bei neuen Versionen nicht nur am Funktionsumfang auf dem Server geschraubt, sondern es sind auch Änderungen an der Clientschnittstelle notwendig, um neue Funktionalitäten gerade im Bereich Sicherheit zu unterstützen. Bei MySQL ist dies zum Beispiel bei der Version 4.1 geschehen, bei der das Protokoll zwischen Client und Server geändert wurde, um höhere Sicherheit bei der Anmeldung und beim Datentransfer zu gewährleisten.
Mit der Version 5.0.x soll MySQL dann einen weiteren bedeutenden Schritt in Richtung der großen Datenbanken tun. Als neue Features kommen dann die lang ersehnten Stored Procedures, Trigger und Views, die sicher viele Entwickler momentan noch vermissen. Für Entwickler ist jetzt natürlich die Frage interessant, wie eine Verbindung zum Server aufgenommen wird, und was es bei den Versionen zu beachten gibt.

Delphi und C++ Builder suchen Anschluss
Die weite Verbreitung von MySQL ist sicher eine der Ursachen, warum Borland mit Einführung des BDE-Nachfolgers dbExpress gleicht noch standardmäßig einen MySQL-Treiber beilegte. Dass dieser etwas lieblos zusammengehackt war, merkte man, sobald man ihn benutzen wollte. Der Treiber war jeweils nur bis zu einer bestimmten MySQL-Version benutzbar und es gab zwischendurch auch kaum Updates von Borland. In solchen Situationen bietet der Markt Platz für Drittanbieter, die sich dann zum Beispiel nur eine Datenbank herauspicken, dies aber richtig gut machen, sodass der Entwickler gern bereit ist, einen kleinen Obolus für das Produkt zu zahlen.
Die wichtigsten Wege von Delphi/C++ Builder zu MySQL kann man sich im Web unter [2] ansehen. Zwei der dort aufgeführten Möglichkeiten wurden bereits im Entwickler vorgestellt, nämlich in [3] und [4]. Bei den kommerziellen Produkten hat man zudem meist die Wahl zwischen Zugriffskomponenten, die ähnlich den IBX-Komponenten genutzt werden und einfach nur zusätzlichen Treibern für dbExpress. Eine Übersicht der Produkte mit Vor- und Nachteilen sowie Performanzbetrachtungen konnten sich die Teilnehmer der EKON 8 in [5] ansehen.

MySQL Data Access Components von Core Lab
Wer mit Delphi auf Datenbanken jenseits von Paradox und dBase zugreifen möchte, hat sich bestimmt schon nach BDE-Alternativen erkundigt und ist besonders im Server-Bereich bei Core Lab [6] fündig geworden. Neben MySQL-Produkten bietet die Firma Zugriffskomponenten, dbExpress-Treiber, BDP.NET- und ADO.NET-Provider für Oracle und den MSSQL Server. Die Besonderheit bei diesen Produkten besteht darin, dass viele auch einen Zugriffsmodus auf die Datenbank kennen, bei denen kein Datenbankclient benötigt wird, also vergleichbar mit den JDBC-Class-4-Treibern.
Bei MySQL ist der mitgelieferte Client sicher nicht so umfangreich wie bei anderen Produkten, hier kann jedoch das Einbinden der Library oder der DLL (libmysql.dll) dazu führen, dass die eigene Software unter die GPL fällt oder entsprechende Lizenzgebühren anfallen.
Zum Ausprobieren der MyDAC-Komponenten genügt die unter [6] herunterladbare Testversion, welche 60 Tage lang getestet werden kann. Eine Vollversion der Komponenten gibt es für rund 70 US-Dollar in der Standard-Version bzw. für etwa 165 US-Dollar in der Professional-Version, welche zusätzlich die Quelltexte beinhaltet. In beiden Produkten sind die Packages für Kylix 2 und 3, C++ Builder 5 und 6 sowie Delphi 5 bis 8 und 2005 enthalten. Bei Delphi 8 und Delphi 2005 wird bei .NET-Programmen nur VCL.NET unterstützt, für reine .NET-Programme ist der ADO.NET-Provider oder der zugehörige BDP.NET-Provider verwendbar, der allerdings ein separates Produkt darstellt. Wir wollen uns in den Beispielen zu diesem Artikel auf Win32-Programme mit dem C++ Builder und Delphi beschränken.

Abbildung 1: Die Komponenten aus dem MyDAC-Package

Installation der Komponenten
Zur Installation gibt es nichts weiter zu sagen, egal ob Trial- oder Vollversion der Komponenten, der Aufruf der exe-Datei aus dem Archiv genügt, alles andere erledigt der Installer. Eine Sache gibt es jedoch noch zu beachten. Zu den Komponenten gibt es noch zwei kleine nützliche Tools, die für die Entwicklung einer MySQL-Anwendung auf jeden Fall empfehlenswert sind, zumal sie kostenlos heruntergeladen werden können. Hierbei handelt es sich zum einen um den DBMonitor, ein Tool das die gleiche Aufgabe wie der SQLMonitor der BDE bzw. der dbExpress-Komponenten erfüllt. Das zweite Tool, MySQLBuilder, dient dem interaktiven Erstellen von SQL-Statements, wobei die Datenbank, die Tabellen und sonstige Kriterien per Mausklick gewählt werden können. Diese Werkzeuge werden wir uns später ansehen. Wurden diese beiden Add-ins nicht installiert, gibt der Installer der MyDAC-Komponenten eine entsprechende Meldung aus, die aber erst einmal ignoriert werden kann. Eine Installation der beiden Tools ist auch später noch möglich.
Standardmäßig werden bis Delphi 7 die Komponenten und zugehörigen Dateien in ein Unterverzeichnis der Entwicklungsumgebung installiert, die Versionen für Delphi 8 und Delphi 2005 können in ein beliebiges Verzeichnis installiert werden. Nach der Installation existiert mit MySQL Access eine neue Seite in der Komponentenpalette der IDE, mit allen in Abbildung 1 sichtbaren Komponenten. Das heißt 13 Komponenten, die mit MySQL zu tun haben und zwei Komponenten als kostenlose Zugabe. Bei letzteren handelt es sich mit dem Namen VirtualTable um ein Tabelle, die ohne Datenbankanbindung im Speicher benutzt werden kann, und ein erweitertes DBGrid.
Neben den Komponenten in der Palette gibt es auch einen neuen Menüpunkt mit Namen MySQL, der den direkten Aufruf der Hilfedatei und einiger Zusatzwerkzeuge sowie Links ins Internet beinhaltet. Einen MySQL-Server zum Testen können Sie sich unter [1] herunterladen und installieren.

Abbildung 2: Der zusätzliche Menüpunkt in der IDE

Verbindungsaufnahme
Die Verbindung zum MySQL-Server wird über die Komponente TMyConnection verwaltet. Neben den für Datenbankserver üblichen Eigenschaften bietet TMyConnection einige spezifische Einstellungen für MySQL, wie die Wahl des zu verwendenden Protokolls (Memory, Pipe, Socket oder TCP/IP) und ob das komprimierte Protokoll verwendet werden soll. Außerdem gibt es die Auswahl, ob sich direkt mit der Datenbank verbunden werden soll oder über die Client-DLL und ob es sich bei der Datenbank um den mit Version 4.0 neuen, embedded Server handelt. Mit einem Doppelklick auf TMyConnection kommt man in den Connection Editor, der übersichtlich die wichtigsten Parameter abfragt, wie in Abbildung 3 zu sehen ist.

Abbildung 3: Der Connection Editor

Das Aktivieren der Datenbankverbindung zur Laufzeit erfolgt wie gewohnt mit der Methode Open oder Connect. Standardmäßig bringt die Connection-Komponente einen Login-Dialog mit, der jedoch auf Englisch beschriftet ist. Wer diesen an die Sprache seines Programms anpassen möchte, findet in der Komponente TMyConnectDialog eine Lösung. Über die Eigenschaft LabelSet kann hier aus mehreren europäischen Sprachen für die Beschriftung der Dialogelemente gewählt werden. Der Dialog wird in der Eigenschaft ConnectDialog der Connection- Komponente eingetragen.
Wem auch das noch nicht komfortabel genug ist, der kann auch einen eigenen Connect-Dialog programmieren, der dann z.B. auch die Auswahl der direkten Verbindung oder der Client-DLL ermöglicht. Ein Beispiel dazu findet sich leider nur in Delphi im Verzeichnis demos\connectdialog in der Datei MyDACConnectForm.pas. Damit ein eigener Dialog als Connect-Dialog eingetragen werden kann, muss die Dialog-Klasse beim Programmstart registriert werden, wie das in C++ funktioniert, zeigt der folgende Quellcode.

void initFormConnect()

{

if(GetClass("TptFormConnect") == NULL)

{

Classes::RegisterClass(__classid(TptFormConnect));

}

}



#pragma startup initFormConnect 64

Hierbei ist TptFormConnect die Klasse des Connect-Dialogs. Mit der #pragma startup-Anweisung wird die angegebene Funktion gleich beim Programmstart ausgeführt, ähnlich dem initialize-Abschnitt in Delphi-Units.
Neben der reinen Verbindungsaufnahme kann die TMyConnection-Klasse aber auch noch andere Aufgaben erfüllen. Sie bietet zum Beispiel verschiedene Informationen über den MySQL Server an, wie die Liste der Datenbanken und der Tabellen und Stored Procedures der aktuellen Datenbank. Diese werden gleich an eine TStrings-Liste übergeben, können also direkt mit einer Combo Box oder List Box dargestellt werden. Die zugehörigen Funktionen heißen GetDatabaseNames, GetTableNames und GetStoredProcNames.
Eine weitere wichtige Aufgabe ist die Verwaltung der Transaktionen, welche MySQL bei bestimmten Tabellentypen unterstützt. Auch hier gibt es mit StartTransaction, Commit und Rollback keine Überraschungen.
Als letztes sei noch die Möglichkeit erwähnt, mit TMyConnection SQL-Befehle auszuführen. Hierbei sollte es sich aber nur um DML- und DDL-Befehle handeln, also SQL-Befehle, die keine Datenmenge zurückliefern. Ein Beispiel bei MySQL wäre der Wechsel der aktuellen Datenbank mit USE DBNAME. Da die Methode ExecSQL von TMyConnection auch parametrisierte SQL-Befehle abarbeiten kann, werden zwei Parameter erwartet, der SQL-Befehl als String und die Parameter als Variant-Array. Beim C++ Builder kommt noch die Parameteranzahl als dritter Parameter hinzu. Für unser Beispiel mit dem Datenbankwechsel könnte der Quelltext wie folgt aussehen:

//Delphi - Variante

procedure TFormMain.btnDBChangeClick(Sender: TObject);

var

params : Variant;

begin

params := Unassigned;

MyConnection1.ExecSQL('USE TEST', params);

end;



//C++ Builder

void __fastcall TFormMain::btnDBChangeClick(TObject *Sender)

{

MyConnection->ExecSQL("USE TEST",NULL,0);

}

Auch hier wird deutlich, dass sich viele Probleme nicht eins zu eins von einer Sprache auf die andere übertragen lassen und dass Delphi nicht immer mit weniger Quellcode auskommt.

Zugriff auf Tabellen
Für den Zugriff auf Tabellendaten bzw. auch die Ausführung von SQL-Statements stehen Komponenten bereit, die in ähnlicher Form bei den BDE- oder auch ADO-Packages zu finden sind. Fangen wir mit TMyCommand an, die von der Funktion her ähnliche Aufgaben wie die ExecSQL-Methode der Connection erfüllen kann. Der SQL-Befehl wird zur Designzeit in einem separaten Editor eingegeben, der gleich noch die Parameter auf einer extra Seite anzeigt und zusätzlich die Möglichkeit bietet, einzelne Abschnitte des SQL-Befehls als so genannte Makros zur Laufzeit zu ersetzen. Die Parameter sind auch von anderen Datenbankbibliotheken her bekannt, mit den Makros kann zum Beispiel die Sortierreihenfolge beim Order By oder auch die Bedingung in der Where-Klausel zur Laufzeit beeinflusst werden. Gekennzeichnet werden die Makros mit einem & vor dem Namen, ansonsten werden sie wie die Parameter angesprochen. Nützlich ist auch das Property InsertId, welches nach Insert-Befehlen auf AUTO_INCREMENT-Felder den automatisch vergebenen Wert enthält.
TMyQuery dient auch zur Ausführung von SQL-Befehlen, hier wird jedoch zusätzlich die Rückgabe einer Datenmenge unterstützt. Damit eine solche Query auch Daten in einer Tabelle ändern kann, besitzt sie nicht nur einen SQL-Befehl, wie das bei den BDE-Queries der Fall ist, sondern für jede mögliche Aktion (Delete, Insert, Refresh, Update) ein separates SQL-Statement. Auf Wunsch kann man sich die erforderlichen Statements auch generieren lassen, nachdem einfach ein SELECT * auf die Tabelle eingegeben wurde (Abb. 4 und 5).

Abbildung 4: Die Felder und Schlüsselfelder

Abbildung 5: Das generierte Insert-Statement

Zusammen mit der Eigenschaft UpdatingTable sind mit TMyQuery auch Join-Abfragen mit Update auf eine einzelne Tabelle des Joins möglich. Die restlichen Eigenschaften und Methoden entsprechen denen der bekannten BDE-Query.
Bleibt als letzte Komponente für den einfachen Datenzugriff noch TMyTable zu nennen. Hier wird dem Entwickler im Prinzip nur die Konfiguration abgenommen, indem einfach aus einer gewählten Tabelle alle notwendigen SQL-Statements im Hintergrund generiert werden. Damit sind natürlich solche Möglichkeiten wie die Joins bei der TMyQuery ausgeschlossen, da nur eine Eigenschaft für den Tabellennamen zur Verfügung steht.
TMyStoredProc dient, wie der Name schon erahnen lässt, zum Ausführen von Stored Procedures, die bei MySQL ab der Version 5 verfügbar sind. Zusätzlich kann die Komponente SQL-Statements für Änderungsaktionen aufnehmen.
Auch für die Unterstützung von Cached-Updates ist mit der Komponente TMyUpdateSQL gesorgt, die Funktionalität entspricht ebenfalls dem BDE-Pendant.
Als letzte Komponente dieser SQL-Gruppe sei noch TMyScript erwähnt, die zur Ausführung von SQL-Skripten gedacht ist. Diese Skripte können auch SELECT-Statements beinhalten, die ihre Ergebnismenge dann an das DataSet in der gleichlautenden Eigenschaft von TMyScript übergeben. Das komplette SQL-Skript wird in das Property SQL, eine Stringliste, geladen und mit der Methode Execute ausgeführt. Die unterwegs auftretenden Fehler können mit dem OnError-Event aufgezeichnet werden.

Add-ins - die Zusatzprogramme
Bei den Zusatzprogrammen wollen wir zuerst einen Blick auf den DBMonitor werfen. Wie schon bei der BDE bieten die MyDAC-Komponenten ein Tracing der SQL-Anweisungen zum Server. Es werden sämtliche SQL-Befehle und sonstige Aktionen wie Connect und Disconnect aufgezeichnet, bei dynamischem SQL mit Angabe der Parameterwerte. Wie die Statements visualisiert werden, kann man mit der Komponente TMySQLMonitor bestimmen. Diese braucht nur einmal mit in die Anwendung aufgenommen zu werden und stellt dann über die Eigenschaft Options als mögliches Ziel der Monitorinformation den Core Labs DBMonitor, den SQLMonitor aus der Enterprise-Version der IDE und/oder einen ganz normalen Dialog. Die letzte Variante ist zum Beispiel gut geeignet, um in der fertigen Anwendung eine Fehlersuche zu ermöglichen. Zusätzlich kann über den TMySQLMonitor eingegrenzt werden, welche Befehle bzw. Abarbeitungsschritte mit angezeigt werden sollen. Fast alle MyDAC-Komponenten können noch über die Eigenschaft Debug einzeln in den Trace-Modus geschaltet werden.

Abbildung 6: Der integrierte Meldungsdialog für SQL-Monitoring

Abbildung 7: Der DBMonitor mit einem parametrisierten SQL-Befehl

Abbildung 6 zeigt den Dialog für das SQL-Monitoring und Abbildung 7 zeigt ein parametrisiertes SQL-Select im DBMonitor.
Das zweite Zusatzwerkzeug, der MySQLBuilder, ist mit dem von Borland bekannten Query Builder vergleichbar. Nachdem man sich mit dem Server verbunden hat, kann man leicht zur gewünschten Datenbank wechseln und mit der Maus eine Abfrage zusammenklicken (Abb. 8). Zur gewählten Datenbank werden die enthaltenen Tabellen gezeigt. Von Auswahlkriterien über Gruppierung und Sortierung bis zu Tabellen-Joins bietet der MySQLBuilder alles was notwendig ist.

Abbildung 8: ein Join im MySQLBuilder

An weiteren eingebauten Tools ist bei der TMyQuery und bei der TMyTable noch der DataEditor zu nennen, der als Browser für die mit der entsprechenden Komponente abgefragte Datenmenge dient. Die Table bietet zusätzlich noch mit Show Create ... auf dem Kontextmenü die Möglichkeit, das Create-Statement für die Tabelle abzufragen. Dies ist besonders dann nützlich, wenn das Datenmodell gerade nicht zur Hand ist oder man nur schnell die Tabellenstruktur überprüfen möchte.

Blob-Felder
Der Zugriff auf Blob-Felder gestaltet sich mit MyDAC ziemlich einfach. Wenn es sich jedoch nicht um Text, sondern um echte Binärdaten handelt, gibt es eine Besonderheit, auf die ich kurz eingehen möchte. Bei mir tauchte in einem aktuellen C++-Builder-Projekt das Problem auf, dass beim Eintragen von Messwerten in ein Blob-Feld einfach Informationen abgeschnitten wurden. Die Hilfe zu den Komponenten gibt zum Thema SetBlobData auch nicht so viel her, sodass nur der Blick in die möglichen Aufrufvarianten der Funktion blieb. Von den zwei Möglichkeiten wählte ich natürlich zuerst die, welche meiner Datenstruktur am nächsten kam, also SetBlobData(void * Buffer). Es zeigte sich jedoch, dass intern der Puffer irgendwie in einen String gewandelt wird, und sobald eine 0 vorkommt, sind die Daten an der Stelle zu Ende, da dies ja als Abschlusszeichen bei Strings benutzt wird. Die zweite Variante SetBlobData(TByteDynArray Buffer, int size) führte dann nach ein paar Performanzuntersuchungen zu folgendem Quellcode:

bool __fastcall TFormMain::PutBlobdata(unsigned char *data, int anzahl)

{

try

{

TBytes bytes;

bytes.set_length(anzahl);

for(int i=0;i<anzahl;i++,data++)

{

bytes[i] = *data;

}

MyCmdIns->ParamByName("DATA")->DataType = ftBlob;

MyCmdIns->ParamByName("DATA")->SetBlobData(bytes,anzahl);

MyCmdIns->Execute(1);

return(true);

}

catch(Exception &ex)

{

MessageBox(NULL,ex.Message.c_str(),"MySQL Fehler",MB_OK);

return(false);

}

}

Der SQL-Befehl in der TMyCommand-Komponente lautet dazu:

INSERT into TESTTAB(DATA) values(:DATA)

Das Primärschlüsselfeld braucht als AUTO_INCREMENT-Feld ja nicht gefüllt werden. In Delphi kann als Puffer zum Beispiel ein array[0..100000]of Byte benutzt werden. Beim Auslesen von Blobs mittels

gelesen = MySelBin->GetBlob("DATA")->Read(0,12000,data);

trat das Problem nicht auf, da hier auf das Feld und nicht auf den Parameter zugegriffen wird.

Datensicherung und Import
Alle MyDAC-Komponenten, die wir noch nicht betrachtet haben, stellen Funktionen bereit, die von den Kommandozeilenwerkzeugen von MySQL, für Datensicherung/-wiederherstellung oder Reparatur bzw. Optimierung von Tabellen angeboten werden.
Der TMyLoader ist für den Import von strukturierten Massendaten gedacht. Er nutzt dazu die Möglichkeit von Blocktransfers beim MySQL. Das funktioniert so, dass mit einem INSERT-Statement mehrere Werte-Klauseln übertragen werden. Wie viele das sind, also wie viele Datensätze auf einmal eingefügt werden, das kann über die Eigenschaft RowsPerQuery angegeben werden. TMyLoader unterstützt zwei Varianten, wie die Daten zur Übertragung aufbereitet werden. Hierzu gibt es die beiden Events OnPutData und OnGetColumnData, von denen einer mit einer Ereignisbehandlungsroutine versehen werden muss. Beim ersten Event wird die Zeile komplett aufgebaut, beim zweiten Event fordert der Loader nacheinander die einzelnen Felder an, wobei neben dem Indexzugriff auf die Felder auch der Zugriff über den Namen möglich ist. Der eigentliche Lade - Prozess startet dann mit der Methode Load, als Ziel wird die gewünschte Tabelle über das Property TableName angegeben. Die Demo-Anwendung zum TMyLoader zeigt recht gut die beiden Varianten der Werteübergabe und man kann ein bisschen mit den verschiedenen Parametern spielen.
Die beiden Komponenten TMyDump und TMyBackup dienen einem ähnlichen Zweck, nämlich der Sicherung und der Wiederherstellung von Tabellen. Der Unterschied besteht in Format und Inhalt der entstehenden Sicherungsdateien. TMyDump erstellt aus der kompletten Datenbank oder aus einzelnen Tabellen ein SQL-Skript, welches mit derselben Komponente wieder eingespielt werden kann, entspricht also dem MySQL-Werkzeug mysqldump. Hierbei können neben den Tabellen mit Daten auch die Nutzerrechte gesichert sowie die Anweisungen zum Erzeugen der Datenbank werden. Der Umfang der Sicherung wird über die Eigenschaft Objects angegeben, der Aufbau des resultierenden Skripts über die Options (Abb. 9).

Abbildung 9: Die Eigenschaften von TMyDump
Im Property TableNames können die zu sichernden Tabellen einzeln angegeben werden, ihre Namen werden dazu, getrennt durch Komma oder Semikolon, angegeben. Das Skript ist nach Ausführung der Methode Backup in der Stringliste SQL verfügbar. Für noch mehr Flexibilität kann alternativ die Methode BackupQuery benutzt werden, um zum Beispiel nur einzelne Felder einer Tabelle zu sichern. Auch bei TMyDump sei an dieser Stelle wieder auf die Demos von MyDAC verwiesen. Abbildung 10 zeigt einen Ausschnitt aus einem mit TMyDump erzeugten Skript.

Abbildung 10: Ein Stück Skript von TMyDump
Während TMyDump von jedem Client aus eine Sicherung ermöglicht, die Sicherungsdaten also über das Netzwerk transportiert werden müssen, wird mit TMyBackup eine Kopie von Tabellen auf dem Server erzeugt. Der Aufruf dazu kann natürlich wieder von jedem beliebigen Client erfolgen, die Sicherungsdateien können aber nur im Dateisystem des Servers abgelegt werden. Die gewünschten Tabellen werden wieder in TableNames angegeben. Für die Sicherung stehen zwei verschiedene Modi, bmBinary und bmText zur Verfügung. Die Binärvariante ist schneller und als Vorgabe eingetragen, aber auf bestimmte Tabellentypen beschränkt. InnoDB-Tabellen lassen sich nur mit dem Textmodus sichern. Zum Textmodus gehören dann noch weitere Angaben, wie die zu verwendenden Trennzeichen für Felder und Datensätze. Das Zurückspielen einer solchen Sicherung erfolgt wie schon bei TMyDump mit der Methode Restore. Bei der Sicherung mit TMyBackup werden zu jeder Tabelle nur die Strukturinformationen und die Daten kopiert, die Datei mit den Indexeinträgen wird beim Rücksichern neu erstellt.

Reparaturarbeiten
Damit sind wir schon fast am Ende unserer Betrachtungen, nur TMyServerControl steht noch aus. Wie der Name schon ahnen lässt, werden mit dieser Komponente verschiedene Wartungsarbeiten durchgeführt. Für jede Aktion gibt es eine separate Methode, so CreateDatabase und DropDatabase zum Anlegen bzw. Löschen von Datenbanken.
Mit Flush können Tabellen und Einstellungen auf dem Server festgeschrieben oder aufgefrischt werden. Die Methode bekommt im Parameter FlushTypes mitgeteilt, was alles geflusht werden soll, also zum Beispiel Tabellen, Logdateien oder die Benutzerprivilegien.
Mit dem Methodenpaar ShowProcessList und KillProcess lassen sich alle aktuellen Prozesse der Datenbank, also auch die Clientverbindungen, auflisten bzw. ein bestimmter Prozess, sprich eine bestimmte Clientverbindung beenden. Da zum Beispiel bei ShowProcessList mehrere Informationen zurückgeliefert werden, ist auch klar, warum TMyServerControl ein Nachfahre von TDataSet ist. Im Feld ID des DataSet findet man dann nach einem ShowProcessList-Aufruf auch den Wert, der für KillProcess als Parameter notwendig ist.
Ähnlich der Prozessliste kann mit ShowStatus abgefragt werden, was der MySQL Server seit seinem Start geleistet hat und mit ShowVariables bekommt man einen Blick auf die Konfigurationsparameter des Servers.
Bleiben als letzte Gruppe noch die Methoden für den Tabellen - Rundumservice. Diese dürften MySQL-Insidern als SQL-Befehle genauso bekannt sein, wie die eben genannten Show-Methoden. Weil hier wieder Tabellen angesprochen werden, finden wir in TMyServerControl auch das bereits bekannte Property TableNames wieder. Mit AnalyzeTable werden statistische Informationen über die Schlüsselverteilung der Datensätze ermittelt und gespeichert. Diese Info's werden beim Abarbeiten von SQL-Befehlen für die Optimierung genutzt. OptimizeTable führt eine Defragmentierung durch, wobei der Platz gelöschter Datensätze wieder verwendet wird und die Tabellen in den meisten Fällen weniger Festplattenplatz benötigen. Diese Methode ist also gerade bei häufigen Löschvorgängen zu empfehlen.
Die Methode CheckTable überprüft die Tabellenstruktur von MyISAM- und InnoDB-Tabellen. Als Parameter erwartet sie die Angabe, wie gründlich das gemacht werden soll.
Bleibt als letzte Methode von TMyServerControl noch RepairTables, welche bei defekten Tabellen versucht, so viele Daten wie möglich zu retten. RepairTables funktioniert momentan nur mit MyISAM-Tabellen. Auch hier wird per Parameter die gewünschte Vorgehensweise angegeben.
Zusammenfassend lässt sich also sagen, dass in TMyServerControl einige nützliche SQL-Statements für eine einfachere Nutzung verpackt sind.

Zugabe
Als kostenlose Zugabe gibt es zwei Komponenten, von denen TVirtualTable bereits erwähnt wurde. Immer dann, wenn man auf strukturierte Daten komfortabel zugreifen oder einen Report von Daten erzeugen möchten, die so nicht in der Datenbank vorkommen, sollte man kurz darüber nachdenken, ob sich das nicht mit dieser In-Memory-Tabelle erledigen lässt. Zumal bei TVirtualTable nicht mit der midas.dll oder irgendwelchen Libraries herumhantiert werden muss.
Die zweite Zusatzkomponente ist ein DBGrid mit eingebauten Sonderfunktionen. So ist zum Beispiel eine Art QBE-Suche realisiert, die sich ohne eine Zeile Quelltext auf das darunter liegende DataSet anwenden lässt. Nach dem selben Schema kann eine Filterzeile eingeblendet werden, in die zur Laufzeit ad hoc ein oder mehrere Filterkriterien eingegeben werden können. Die Komponente heißt TCRDBGrid und ist nur für Windows verfügbar.

Fazit
Man merkt der Komponentensammlung MyDAC an, dass ihre Schöpfer schon eine ganze Zeit lang profesionelle Datenzugriffstechnologien entwickeln. Wenn man also mit Borland-IDEs auf MySQL zugreifen möchte, sollte man sich auf jeden Fall die Core Labs - Komponenten anschauen. Der Preis für die Standard-Version ist auch sehr human, zumal alle Updates des aktuellen Hauptreleases kostenlos downloadbar sind.

Links & Literatur

[1] www.mysql.com
[2] delphi.about.com/cs/toppicks/tp/aatpmysql.htm
[3] T. Wassermann: Heute schon (ab)gefragt, in Der Entwickler 2.2004
[4] P. von der Born: MySQL-Datenbank im Griff, in Der Entwickler 4.2004
[5] P. Tabatt, Datenzugriffskomponenten für MySQL, EKON 8
[6] www.crlab.com/mydac

	Der Entwickler \| dot.net magazin \| Eclipse Magazin \| Entwickler Magazin \| Java Magazin \| Linux Enterprise \| PHP Magazin \| CREATE OR DIE \| Business Technology