Access oder MySQL

[MmVisual]

Am besten die ZEOS Komponente nehmen, die geht auch mit Delphi und beherrscht durch einfaches Umparametrieren viele Datenbanken, z.B. MySQL, SQLite, MsSQL, Firebird, PostgreSQL, ASA, ... Und die Entwickler sind aktiv am Projekt und es wird ständig erweitert!
Ich nutze die schon seit Jahren und die funktioniert gut.

[mschnell]

Unter Delphi gibt es zahlreiche Implementierungen der ADO-Schnittstelle unter Windows...,

Den Sinn des Satzes verstehe ich nicht ganz. Wenn die Datenbank einen ADO - Treiber zur Verfügung stellt braucht die Programmiersprache für den Zugriff nur die ADO Schnittstelle zu benutzen. Sie braucht von der Beschaffenheit des Datenbank-Programms nichts zu wissen. Nur für die Erstellung der Datenbank und der Tabels braucht man eine spezifische Kommunikation mit dem Server. Dafür kann man aber oft die jeweils mitgelieferten Bedien-Programme und Scripts verwenden.

Ich habe z.B. ein Programm (nicht von mir) auf eine Postgres Datenbank zugreifen lassen, das von Postgres überhaupt nichts wusste (es war in der Doku nur von MSSQL die Rede). Dafür musste ich natürlich die Datenbank mit der Postgres Oberfläche erst einmal erstellen.

In Windows ist der SQL-Zugriff mit ADO also ziemlich gut normiert. Keine Ahnung, wie das in Linux aussieht.

-Michael

[gocher]

Soweit ich weiß existiert ActiveX Data Objects (ADO) nur unter Windows,
C:\Program Files\Common Files\System\ado\msado15.dll genutzt wird im Regelfall C:\WINDOWS\system32\stdole2.tlb.
Die ADO-Schnittstelle ist sehr vereinfacht ausgedrückt ein Wrapper der den Zugriff auf Datenbankschnittstellen vereinheitlicht und so kann über eine Connection (http://www.connectionstrings.com/) auf unterschiedlichste Datenbanktreiber zugegriffen werden. Die ADO-Schnittstelle stellt einige Objekte zur Verfügung wie z.B. Connection, Recordset, Command und Fields.
Wenn man über Lazarus Werkzeuge -> Import Type Libray C:\Program Files\Common Files\System\ado\msado15.dll importiert wird eine ca. 4700 Zeilen lange Interface Datei angelegt über die bereits ein Zugriff möglich ist aber halt nicht sehr komfortabel.
Natürlich kann man auch mit OLE (CreateOleObject) und OleVariant arbeiten was aber noch unsauberer ist.
Das was ich mit "Implementierung der ADO-Schnittstelle" meinte ist eine saubere objektorientierte typensichere (also ohne Variant) Schnittstelle, die trotz dem nicht zu komplex ist und auch vielleicht noch andere schöne Möglichkeiten aus ADOX, JRO ... mit einbezieht um z.B. Eine Datenbank zu komprimieren und zu Reparieren usw.

[mschnell]

Das was ich mit "Implementierung der ADO-Schnittstelle" meinte ist eine saubere objektorientierte typensichere (also ohne Variant) Schnittstelle, die trotz dem nicht zu komplex ist

OK. Das sollte aber nur auf ADO zugreifen und damit unabhängig von der Art der Datenbank (Datei-basiert/Jet, MSSQL, MySQL, Postgres, ...) sein.

...und auch vielleicht noch andere schöne Möglichkeiten aus ADOX, JRO ... mit einbezieht um z.B. Eine Datenbank zu komprimieren und zu Reparieren usw.

... und vor allem Datenbanken Erzeugen und Tabellen in ihnen definieren.

Damit ist das natürlich abhängig von der Art der Datenbank und es muss eine Variante für jeden unterstützten Datenbank-Typ erstellt werden.

-Michael

[gocher]

Also Tabellen erzeuge ich immer noch mit dem SQL Befehl CREATE TABLE natürlich variieren die Befehle ein wenig, alleine schon durch die Feldtypen, aber das sehe ich nicht als so kritisch an. Datenbanken zu erstellen inklusive Einrichtung der Rechte etc. ist ab einer bestimmten Komplexität sowieso problematisch, bei Access erzeuge ich schon mal eine neue Datenbank über ADOX da macht es noch Sinn.

Code: Alles auswählen

procedure CreateDB(const Filename: string);
var cat: ADOX._Catalog;
begin
  try
    cat := CreateADOObject(CLASS_Catalog) AS ADOX._Catalog;
    cat.Create('Provider=Microsoft.Jet.OLEDB.4.0;Data Source=' + Filename + ';');
    cat := nil;
  except
    on e: Exception do
      raise Exception.Create(e.Message);
  end;
end;

Komprimieren geht auch noch über JRO

Code: Alles auswählen

 
procedure CompactDB(const Filename: string);
var
  jro: JetEngine;
  FilenameNeu:string;
begin
  try
    FilenameNeu := ChangeFileExt(Filename, '~.mdb');
    jro := CreateADOObject(CLASS_JetEngine) AS JetEngine;
    jro.CompactDatabase('Provider=Microsoft.Jet.OLEDB.4.0;Data Source=' + Filename + ';',
           'Provider=Microsoft.Jet.OLEDB.4.0;Data Source=' + FilenameNeu + ';');
    if FileExists(FilenameNeu) then
    begin
      DeleteFile(PChar(Filename));
      RenameFile(FilenameNeu, Filename);
    end;
    jro := nil;
  except
    DeleteFile(PChar(filenameNeu));
  end;
end; 
 

Funktionen losgelöst aus meiner Klasse
ADOX: C:\Programme\Gemeinsame Dateien\System\ado\msADOX.dll
JRO: C:\Programme\Gemeinsame Dateien\System\ado\msjro.dll
erforderlich!

[mschnell]

Alles gut und schön.

Die Frage ist nur, welche Funktionalität die jeweilige ADO DLL in welcher Art realisiert.

Der SQL Zugriff auf Daten mit "normalen" Typen ist in jedem Fall immer gleich. Das Programm braucht also nicht zu wissen, welche Datenbank angeschlossen ist.

Die SQL-Befehle zum Erzeugen von Tabellen sind - soweit ich weiß - nicht genormt.

-Michael

[mschnell]

Mich würde schon interessieren, ob es so eine "Standard-SQL-Daten-Zugriffs-Methodik" in Linux auch gibt.

Für .NET habe ich das gefunden:

http://blogs.msdn.com/b/adonet/archive/ ... linux.aspx

Ist das Thema hier "ODBC" ? http://www.easysoft.com/developer/inter ... linux.html

-Michael

[mschnell]

Der SQL Zugriff auf Daten mit "normalen" Typen ist in jedem Fall immer gleich. Das Programm braucht also nicht zu wissen, welche Datenbank angeschlossen ist.

Für Client-Server-Datenbanken ist ja eigentlich sogar das SQL-Protokoll (via TCP/IP) für den normalen Daten-Zugriff Hersteller-unabhängig genormt. Demzufolge sollte es noch nicht einmal nötig sein, auf dem Rechner einen zum Datenbank-Server passenden ADO-Treiber zu installieren. Eigentlich könnte das Programm auch ohne ADO direkt mit einem Socket SQL-Verkehr über TCP/IP machen. Das wäre dann auch Plattform-unabgängig. Ich vermute, die ADO-Schicht ist hauptsächlich erfunden worden, um Programmen einen SQL-konformen Zugriff zur Datei-basierten Microsoft JET Datenbank zu ermöglichen.

Besser wäre gewesen, eine JET-Server-DLL mit TCP-IP-(Server) Schnittstelle zu verwenden. Aber in Windows ist es - anders als in Linux - ja nicht üblich (und nicht performant) Programme Rechner-Intern über TCP/IP zu koppeln.

Vielleicht gibt es für Linux ja sogar so ein JET-Server-Ding ?!?!?

-Michael

[gocher]

Zur Klarstellung der Datenbankzugriff mit ADO (ActiveX Data Objects) geschieht über den OLE DB-Provider unter Verwendung der ODBC-Schnittstelle, ADO an sich ist kein Treiber sondern ein ActiveX Objekt wie der Name schon sagt!

[MmVisual]

Die ZEOS Komponente kann auch den FreeTDS Treiber verwenden. Damit wäre eine Verbindung zu einem MsSQL Server möglich.

[mschnell]

Zur Klarstellung der Datenbankzugriff mit ADO geschieht über den OLE DB-Provider unter Verwendung der ODBC-Schnittstelle, ADO an sich ist kein Treiber!

Danke für den Hinweis. Ich weiß damit zwar nicht mehr, was ADO eigentlich ist, aber ich meinte natürlich tatsächlich die Schnittstelle, die ein Programm verwenden kann und die heißt dann wohl "OLE DB-Provider".

Jedenfalls finde ich es eine blöde Idee diese "OLE DB-Provider" Schnittstelle zu erfinden, statt einfach SQL über TCP/IP auch lokal zu verwenden. (Ursprünglich ist SQL ja so gedacht, dass ein Programm über einen Socket einen Datenbank-Server anspricht. Dann braucht man weder OLE, noch ODBC noch ADO.)

-Michael

[af0815]

Jedenfalls finde ich es eine blöde Idee diese "OLE DB-Provider" Schnittstelle zu erfinden, statt einfach SQL über TCP/IP auch lokal zu verwenden. (Ursprünglich ist SQL ja so gedacht, dass ein Programm über einen Socket einen Datenbank-Server anspricht. Dann braucht man weder OLE, noch ODBC noch ADO.)

-Michael

Und wie gehst du mit der Antwort um ? DIe kann sehr komplex ausfallen. Vom Fehler über einzelne Werte bis zu mehrer inhomogenen Datenmengen ist alles möglich Wie fragst du Metadaten ab ?

Zu Infos über ADO siehe auch auf der englischen Doku von Microsoft

ADO greift über OLE DB zu und stellt eigentlich eine Abstraktionsschicht für die verschiedenen OLE DB dar. Ähnlich wie das Konzept von der legendären BDE (Borland Database Engine). Der aktuelle Vergleich wäre ZEOS. Nachdem ADO von MS kommt ist es natürlich auf Windows abgestimmt.

[mschnell]

Und wie gehst du mit der Antwort um ? DIe kann sehr komplex ausfallen. Vom Fehler über einzelne Werte bis zu mehrer inhomogenen Datenmengen ist alles möglich Wie fragst du Metadaten ab ?

Das dekodieren der Antworten ist doch ohnehin Aufgabe des Programmes (z.B. der ZEOS-Library) und nicht der OLE-db-Provider oder ADO Schicht. Oder täusche ich mich da ?

Die Syntax der Antworten sollte doch im SQL-Standard entsprechend definiert sein, solange keine Nicht-Standardmäßigen Erweiterungen verwendet werden, die bestimmte Datenbank-Server implementiert haben (aber sicherlich nicht JET)

Ich hoffe doch, dass alles, was man üblicherweise braucht vom SQL (über TCP/IP) -Standard Hersteller- und OS- unabhängig abgedeckt ist, neben den von Dir genannten "Antworten" auch Trigger/Events, Stored Procedures, Transaktionen, ...

-Michael

[mschnell]

ADO greift über OLE DB zu und stellt eigentlich eine Abstraktionsschicht für die verschiedenen OLE DB dar. Ähnlich wie das Konzept von der legendären BDE (Borland Database Engine). Der aktuelle Vergleich wäre ZEOS. Nachdem ADO von MS kommt ist es natürlich auf Windows abgestimmt.

Verstehe ich nicht "OLE DB" und "ADO" sind doch außerhalb des User-Programms in Windows installiert, während die ZEOS Library in das User-Programm eingebaut wird. Welche Schnittstelle Richtung Datenbank-Server verwendet denn ZEOS ? Doch wohl nicht tatsächlich direkt einen TCP/IP Socket ? (Ich hatte vermutet, es verwendet zumindest auf Windows ADO / OLE DB.)

-Michael

[MmVisual]

>Welche Schnittstelle Richtung Datenbank-Server verwendet denn ZEOS ?

ZEOS nutzt immer eine DLL und hat keinen eigenen TCP/IP Treiber. Wenn man MySQL nehmen will, so benötigt ZEOS die Client DLL diese DB. So auch bei MsSQL oder PostgrSQL oder SQLite. Die DLL wird je nach DB Typ dynamisch geladen.