Delphi 8 mit MySQL 4.0 verbinden

[Markus Reimann]

Hallo Leute,

Ich habe folgendes Problem: Ich muss Delphi 8 mit MySQL 4.0 verbinden. Bis vor kurzem habe ich noch mit Delphi 7 gearbeitet und wollte das mit dbExpress regeln, was allerdings nicht ging, da eine benötigte .dll-Datei von Delphi 7 MySQL nicht bis zur Version 4.0 unterstützt, trotz der neueren aus dem Internet heruntergeladenden Datei und einem Eintrag in die entsprechnden Datei. Mit Delphi 8 hat es auf Anhieb und vollkommen problemlos funktioniert.
Zur Zeit lese allerdings ich folgende Lektüre: "Crashkurs .NET für Delphianer". Inzwischen bin ich mir nicht mehr sicher, ob ich das nicht wegen dieser ganzen .NET-Technologie lieber mit ADO.NET regele. Wenn ich das richtig verstanden habe, greift ADO.NET auch direkt auf die Klassen des .NET-Framework zu, während das bei dbExpress.NET nicht der Fall ist. Ist das so richtig?

Vielen Dank schon mal im voraus für jede Antwort.

Markus Reimann

[Andreas Kosch]

Hallo,

angesichts von <i>Longhorn</i> und <i>WinFX</i> wird die VCL.NET in der Tat nur noch eine absehbare Lebensdauer haben. Dies bedeutet aber nicht, dass man aus diesem Grund bereits Heute darauf verzichten muss.

&gt;..während das bei dbExpress.NET nicht der Fall ist.

In der Tat greifen die VCL.NET-Komponenten stellenweise parallel zum .NET-Framework als nichtverwalteter Programmcode (unmanaged Code) direkt auf Win32-DLLs zu. Die .NET-Anwendung schaltet daher ständig auf den "alten" Modus zurück, so dass es einige unerwünschte Nebenwirkungen (Performance-Einbußen, höhere Anforderungen an die .NET-Rechte, stellenweise Probleme bei der Zusammenarbeit mit anderen Assemblies etc.) gibt.

Alternativ zu dbExpress stehen die <b>BDP.NET</b>-Komponenten zur Verfügung, die reine .NET-Klasen sind und allein deshalb "besser" sind. Die Frage lautet aber hier, wann es einen MySQL-Treiber gibt

[Markus Reimann]

Hallo Andreas,

danke erstmal für die schnelle Antwort. Wieso stellt sich hier die Frage nach einem MySQL-Treiber? Delphi 8 hat doch einen aktuellen. Wie gesagt funktioniert das da einwandfrei. Mein Problem ist, dass ich nicht weiß, mit welcher Verbindungskomponente ich am besten arbeite. Der Hauptfaktor ist natürlich die Zeit. Das heißt, die Kommunikation zwischen Delphi 8 und MySQL 4.0 soll so wenig wie möglich Performence beanspruchen, damit zur Laufzeit eine schnelle Verbindung zu Stande kommt. Der nächste Faktor, ist die Aktualität der Verbindungskomponente. Ich möchte also eine Verbindungskomponente nutzen, die dauerhaft aktuell ist und für ein langfristiges großes Projekt Sinn macht. Ich möchte keine Komponente benutzen, die in absehbarer Zeit nur noch der Abwärtskompatibilität wegen unterstützt wird. Meine Frage ist also folgende: <B>Mit welcher Komponente verbinde ich idealerweise Delphi 8 und MySQL 4.0?</B>

Gruß Markus Reiman

[Andreas Kosch]

Hallo,

&gt;Delphi 8 hat doch einen aktuellen

aber nicht für den .NET-Weg über BDP.NET. Borland schreibt dazu in dem Papier <i>Borland ® Data Provider (BDP) for the Microsoft® .NET Framework</i> (siehe <i>http://community.borland.com/article/0,1410,31939,00.html</i>) folgendes: "<i>BDP currently supports Borland InterBase, Oracle, IBM DB2, and Microsoft SQL Server 2000</i>".

&gt;Mit welcher Komponente verbinde ich idealerweise Delphi 8 und MySQL 4.0?

Wenn in Delphi 8 die Vorteile der visuellen Entwicklung in einer zukunftsfähigen Implementierung genutzt werden sollen, wäre BDP.NET die richtige Wahl (dort gibt es aber noch keinen offiziellen MySQL-Treiber). Alternativ dazu stehen die nativen ADO.NET-Verbindungsklassen aus dem .NET Framework zur Verfügung, die auch "alte" ODBC-Treiber und OLE DB-Provider einbinden können und somit eine größere Bandbreite an Datenbanken unterstützen als BDP.NET. Nur im Fall der nativen ADO.NET-Klassen stellt Delphi 8 im Gegensatz zum Konkurrenten Visual Studio .NET <b>keine</b> Wizards zur bequemen Konfiguration der Eigenschaften zur Verfügung. Wir können nur die ADO.NET-Komponenten ablegen, aber im Objektinspektor müssen alle Eigenschaften von Hand in der richtigen Syntax eingetippt werden.

Fazit: Es gibt in Delphi 8 keinen idealen Zugriffsweg auf eine MySQL-Datenbank. In jedem Fall sind Kompromisse notwendig (Wahl des kleineren Übels)

[Christian Storfinger]

Hallo zusammen,<br>
<br>
ich verfolge seit längerem die Diskussionen, die sich immer um die Thematik drehen, ob für neue Projekte das .NET-Framework in irgendwelcher Weise verwendet werden soll oder eben nicht.<br><br>
Ich beobachte seit dem Erscheinen von Delphi 6 einen - meiner Meinung nach - ständigen Richtungswechsel von Borland in Sachen Datenbankzugriff mit Delphi-Bordmitteln. Kaum beschäftigt man sich näher mit ADO.NET, tauchen erste Gerüchte vom Ende der Weiterentwicklung auf. Das obige Posting von Hr. Kosch bestätigt meine Vermutungen.<br><br>Ich persönlich bin seit langem relativ verunsichert, welche Zugriffstechnik ich für neue, längerfristig angelegte Projekt verwenden soll und damit im Zusammenhang, ob der Einsatz einer neuen Delphi-Version sinnvoll ist. Im Endeffekt erscheint mir momentan Delphi 5 - mit dem ich seit der Veröffentlichung arbeite und ziemlich zufrieden bin - mit ADO und IBX immer noch als bessere Delphi-Version, weil mir dbExpress, ADO.NET und auch oben genanntes BDP.NET als zu unsicher erscheinen.<br><br>
Seid Ihr anderer Meinung? Wer von Euch kann für eine Anwendung, die auch in fünf Jahren noch gepflegt werden soll, Komponenten für den Datenbankzugriff aus Delphi vorbehaltlos empfehlen?<br>
<br>
Viele Grüße,<br>
Christia

[Andreas Kosch]

Hallo,

&gt;...ständigen Richtungswechsel von Borland in Sachen Datenbankzugriff...

In der Tat, aber das gilt nicht nur für den Datenbankzugriff. Bei den Report-Tools oder den Web-Anwendungen ist das noch gravierender.

&gt;..tauchen erste Gerüchte vom Ende der Weiterentwicklung auf...

Das ist der Lauf der Dinge. Ungefähr alle 10 Jahre kommt es in unserer Branche zu einem grundlegenden Wechsel: <br>
a) 1990: DOS -> Windows 3.x <br>
b) 2000: Win32 -> .NET <br>
c) 200?: .NET -> WinFX (Avalon, Indigo, Win FS usw.)

Wenn man sich die Unterlagen von der PDC2003 aber genau anschaut, verspricht Microsoft einen bequemen 1:1-Migrationsweg, so dass es Heute <b>keinen</b> Grund gibt, neue Projekte <b>nicht</b> mit ADO.NET anzufangen. Denn das bisherige ADO.NET verschwindet ja nicht, sondern wird nur erweitert (Namespace <i>System.Storage</i> und die <i>ObjectSpaces</i>).

Der Vorteil des .NET Frameworks liegt ja unter anderem auch darin, dass eine Zwischenschicht zwischen den "Low-Level-API-Funktionen" des Betriebssystems und underen Anwendungen eingezogen wird. Bei einem grundlegenden Umbau des Betriebssystems muss dann nur dieser Layer von Microsoft mit angepasst werden.

&gt;..für neue, längerfristig angelegte Projekt verwenden soll.

Das ist eine generelle Frage. Die Sprachen wie VB.NET oder Delphi "gehören" einer Firma, so dass es immer die Gefahr von sprunghaften Veränderungen geben wird. Das war auch bisher bei VB so, so dass Borland mit seinem Delphi keine Ausnahme darstellt.

Die Sprache C# hingegen ist standardisiert, so dass es aufgrund des sich daraus ergebenenden Abstimmungsprozesses zwischen allen Beteiligten keine "schnellen Sprünge" geben kann. Wenn der Schwerpunkt auf die mehrjährige Software-Pflege gelegt wird, ist in meinen Augen C# die 1. Wahl. Zumal mehrere Entwicklungs-Umgebungen für C# verfügbar sind und eine davon aus dem Open-Source-Lager kommt (so dass im Worst Case immer noch eine Alternative übrig bleibt)

[Bernhard Geyer]

Hallo Christian,

> Ich beobachte seit dem Erscheinen von Delphi 6 einen - meiner Meinung nach - ständigen Richtungswechsel von Borland in Sachen Datenbankzugriff mit Delphi-Bordmitteln.

Selbst ist mir dieser Richtungswechsel bisher egal gewesen, da wir immer native Zugriffskomponenten verwenden, welche maximal nur auf TDataset aufsetzen. Und da dieses TDataset auch in D8 vorhanden ist müssen wir nur noch hoffen das auch die Komponentenhersteller entsprechend nachziehen.
Grundsätzlich ist eine Kapselung der DB-Funktionalität für Zukunftssicherheit und Portabilität angebracht. Hierbei kann die verwendung des Bridge-Patterns sehr nützlich sein. Jedoch wirst Du mit dieser Kapslung die Möglichkeiten der DB-Sensitiven Komponenten größtenteils verlieren.

> Ich persönlich bin seit langem relativ verunsichert, welche Zugriffstechnik ich für neue, längerfristig angelegte Projekt verwenden soll

Durch Verwendung einer Kapslung ist dieses Problem eigentlich behoben. Selbst setzen wir (noch) auf BDE für Altprojekte, native Zugriff auf Oraclet Net-Schnittstelle und für MS-SQL ADO.

Grundsätzlich ist das Konzept von ADO.NET auch darauf ausgelegt das nur ein relativer kleiner Teil Datenbank-Abhänig (SQL-Syntax, Möglichkeiten) ist und möglichst schnell in den DB-Unabhängigen Teil (Dataset) verfrachtet werden soll

[Markus Reimann]

Hallo,

den letzten Einträgen nach zu urteilen, würde ich mich für ADO.NET entscheiden, auch wenn sich das etwas schwieriger als beispielsweise mit dbExpress gestaltet. Wenn ich das alles richtig verstanden habe und meine weiteren Informationen auch richtig sind, würde ich glatt im vornherein unter allen Umständen versuchen, mich von der Verwendung von VCL-Komponenten fernzuhalten. Ich würde gleich eine WinForms-Anwendung erstellen und sämtliche VCL-Komponenten meiden. Allerdings werde ich aus der Aussage von Andreas Kosch nicht ganz schlau:

'Wir können nur die ADO.NET-Komponenten ablegen, aber im Objektinspektor müssen alle Eigenschaften von Hand in der richtigen Syntax eingetippt werden.'

Ich habe zu Testzwecken eine kleine Datenbank in MySQL erstellt und habe eine WinForms-Anwendung erstellt, mit der ich diese Datenbank bearbeiten möchte. Ich wüsste jetzt auch nicht auf Anhieb, wie ich aus dieser WinForms-Anwendung mittels irgendwelcher VCL-Komponenten eine Verbindung zu MySQL herstellen sollte. Aber das interessiert mich eigentlich auch nicht weiter, da ich wie gesagt sämtliche VCL-Komponenten meiden möchte. Mein Problem ist folgendes: Ich finde erst gar keine ADO.NET-Komponenten. Ist ADO.NET womöglich eine VCL-Komponente? Oder wie läuft das? Könnte mir das einer etwas genauer erklären?

Marku

[Andreas Kosch]

Hallo,

&gt;Ich finde erst gar keine ADO.NET-Komponenten...

wenn in Delphi 8 ein Windows Forms-Projekt (keine VCL.NET!) geöffnet wird, sollte die Tool-Palette im Abschnitt <i>Data Components</i> die 3 Komponenten SqlDataAdapter, SqlCommand und SqlConnection anzeigen. Die restlichen ADO.NET-Komponenten für ODBC und OleDb fehlen in der Voreinstellung - diese müssen erst einmalig in die Toolpalette von Delphi 8 installiert werden: <br>
a) Menüpunkt Components | Installed .NET Components <br>
b) Registerseite .NET Components <br>
c) Checkbox vor den Odbc- und OleDb-Komponenten (bis auch CommandBuilder) ankreuzen<br>
d) Category: Auf Data Components änder