Access oder MySQL

[MmVisual]

Das mit Zeos/FreeTDS würde ich gerne mal selbst testen. Woher kann ich die DLL bekommen?

[Christian]

Weiss ned was sagt denn die Suchmaschiene deiner Wahl ?

[mschnell]

Nun noch was an Michael TCP/IP ist ein Protokoll zum Datentransfer, die Kommunikation funktioniert also Client-Server, was natürlich bei vielen Serverdatenbanken möglich ist, für den Zugriff auf die Daten wird also ein Client (Treiber) benötigt, der die Befehle und die Rückgabe zur Verfügung stellt.

Mit TCP/IP kenne ich mich bestens aus (mit SQL allerdings weniger). Ich war davon ausgegangen, dass man den standardisierten SQL-Byte-Strom, der in den genannten Dokumenten definiert ist, einfach über eine transparente TCP/IP Connection zwischen client und Server kommunizieren kann. Wenn das nicht so ist, braucht man am Client natürlich eine Hersteller-Spezifische Bibliothek, die mit dem User Programm SQL spricht und mit dem Datenbank-Server in proprietärer Weise. Fände ich aber eine ziemlich blöde Idee. (Außer, dass man da z.B. eine Kompression einbauen könnte.)

"Client-Server" heißt ja nicht unbedingt, dass der Server auf einem anderen Rechner laufen muss. In Linux macht man sehr erfolgreich und performant TCP/IP Kommunikation zwischen Programmen auf derselben Hardware. Statt TCP/IP kann man natürlich zur Rechner-Internen Client-Server-Kommunikation mit Byte-Streams Pipes verwenden, was noch etwas performanter ist und für die beteiligten Programme außer beim öffnen keinen Unterschied macht ("In Linux ist alles eine Date") .

Ich hatte ja auch ausgeführt, dass ich nur von Client-Server-SQL-Datenbanken spreche. Ein SQL-Server-Programm, das auf demselben Rechner läuft, wie das User-Programm und einer JET-Datebank, deren Flat-File für den gemeinsamen Zugriff auf einem Fileserver liegt, ist aber absolut denkbar und würde das Kriterium "Cleint-Server" durchaus erfüllen. Wenn ich das richtig sehe, macht JET-via-ADO so etwas ähnliches (nur eben nicht über TCP/IP).

-Michael

[mschnell]

Zeos vereinheitlicht nun über die eigene Schnittstelle, das bedeutet wenn man nun von Windows nach Linux wechselt geht das auch, nur nicht unbedingt mit der selben Datenbank. Denn wenn man unter Windows einen MSSQL Server zur Verfügung hat, gibt es den unter Linux nicht.

Das wäre ja vollkommen idiotisch. Ist das Zeos Team damit wirklich zufrieden ?

Gibt es keine "allgemeine" DLL/so, die die von Zeos verlangte Programmier-Schnittstelle bietet und Richtung Datenbank nicht mehr als die standardisierte SQL-Kommunikkation via TCP/IP verwendet, und dabei natürlich keine Hersteller-Spezifischen Erweiterungen (siehe Wiki-Artikel über SQL) zur Verfügung stellt, was natürlich die vom User verwendbaren Möglichkeiten einschränkt, ihm aber jederzeit den Wechsel des Server-Herstellers ohne neu-kompilieren und installieren von irgendwelchen "Treibern" auf den Client-Rechnern ermöglicht.

Realisiert MSSQL den SQL-Standard gar nicht (würde mich nicht unbedingt wundern... )

-Michael

[mschnell]

Solange hier behauptet wird Zeos greife überer ADO zu macht eine Diskussion keinen Sinn. Glaube nur selbst an deine Märchen.hde

Die Behauptung ist ursprünglich nicht hier aufgestellt werden, sondern ich habe (mit Quellen-Angabe) aus "Delphi-Praxis" zitiert.

Lügen die ?

-Michael

[mschnell]

hde hat recht. Zeos nutzt direkt die Client DLL / SO. Und wo ist jetzt die ADO DLL dazwischen?

Da ZEOS - soweit ich das inzwischen verstanden habe - für jeden unterstützte Datenbank-Typ eigenen Code beinhaltet, kann es ja teilweise über ADO gehen und teilweise über andere DLL/so- API - Schnittstellen. Es könnte theoretisch für irgendeinen (zukünftigen) Type auch SQL-Kommunikation selber über TCP/IP-Sockets oder Pipes realisieren, ohne eine externe Laufzeitbibliothek zu benötigen.

Das ist doch kein Widerspruch.

-Michael

[mschnell]

Irgendwo habt ihr alle recht aber doch auch keiner

Ist schon schade, dass jeder nur das für wahr hält, was er schon kennt, und die Augen vor alternativen Möglichkeiten verschließt.

Dabei ging es in der Ursprünglichen Frage doch um die Auswahl, d.h. zunächst um die Beleuchtung von Möglichkeiten ...
-Michael

[Christian]

Wie schon geschrieben, man kann durchaus auch unter Linux auf MSSQL Datenbanken zugreifen.
Und ja kein Datenbankhersteller hat interesse daran das man einfach auf eine andere Datenbank wechseln kann, genauso wie kein Office Hersteller interesse daran hat das sein Dateiformat von der Konkurenz fehlerfrei gelesen werden kann.
Schaltet soch bitte das Hirn mal ein.

[MmVisual]

In der ZEOS SVN gibt es eine Text Datei, wo drin steht welche DLL man braucht und wo man die laden kann. Leider klappt das dennoch nicht mit dem FreeTDS Treiber. Die DLL "dblib.dll" habe ich auch angegeben. Wenn ich mal Zeit habe, dann mache ich dafür einen separaten Thread auf. Es ist sicher nur eine andere Konfiguration nötig, die ich noch nicht herausgefunden habe. Denn der Zeos-Entwickler hatte mir schon vor längerer Zeit geschrieben, dass nun FreeTDS fertig implementiert ist. Ich wollte das nur mal mit meinem EleLa Programm testen (Seit ein paar Tagen unterstützt EleLa auch MsSQL und nicht nur MySQL/PostgreSQL/SQLite (über die Zeos Komponente)).

[gocher]

Jedenfalls finde ich dieses komische "cn := CreateOleObject('ADODB.Connection');" sehr unpraktisch. Wenn man nun ein cn. im Editor eintippt, dann erscheinen alle möglichen Dinge in der Auswahlliste, aber niemals die, die mit dem ADO Objekt zusammen passen. Also man muss alle Methoden vom OLE Objekt auswendig wissen. Und das soll eine tolle und einfache Programmierung sein Na dann viel Spaß mit ADO / OLE Objekten.

Hallo, ich habe extra unter dem Code folgendes geschrieben:

Für dieses Beispiel ist nicht einmal der Import der Type Library von ADO erforderlich, da ich für dieses Beispiel einfach mal auf OLE Objects aufgesetzt habe, mal so kurz zum Test, ist zwar nicht komfortabel aber geht auch !

Ich wollte lediglich mit diesem Beispiel klarstellen, was alles geht, ich habe zuvor geschrieben das ich die ADO Type Libray als Grundlage für eine eigene Klasse nutze, da funktioniert auch die Code-Vervollständigung.
Ich habe auch nicht behauptet das Zeos immer über ADO zugreift!
Ich habe sogar davon abgeraten ADO zu nutzen wenn man eventuell einen System-Wechsel einplanen muss!
Ich habe am Anfang sogar geschrieben das der Weg über ADO sehr steinig ist, weil man selbst was schreiben muss und nicht einfach eine fertige Komponente nutzen kann. Was muss ich sonst noch alles schreiben.
Aber wenn man erst einmal eine ADO Komponente geschrieben hat und sich unter Windows um nichts mehr kümmern muss ist es eine feine einfache Sache!

[Christian]

Der Weg über ADO ist nicht steinig, Zeos kann das bereits

[gocher]

Mal ein Beispiel, zum besseren Verständnis, wie würde so ein kleines Progrämmchen unter Zeos aussehen?

Code: Alles auswählen

program ADOTest;
{$APPTYPE CONSOLE}
{$mode objfpc}{$H+}
uses Classes, SysUtils, ado;
 
function IIF(b: boolean; sTrue: string; sFalse: string = ''): string;
begin if b then result := sTrue else result := sFalse; end;
 
var
  cn: TADOConnection;
  rs: TADORecordset;
  i: integer;
begin
  //connect db
  cn := TADOConnection.Create(nil);
  cn.Open('Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\mydb\test.mdb');
//  cn.Open('Provider=MSDASQL.1;Extended Properties="Driver={MySQL ODBC 3.51 Driver};Server=localhost;Port=3306;Database=test;User=root;Option=3;"'; //MySQL
//  cn.Open('Provider=SQLOLEDB.1;Password=mypass;User ID=root;Initial Catalog=test;Data Source=localhost;'); //MSSQL
  //select
  rs := TADORecordset.Create(cn);
  rs.Open('SELECT * FROM tblTable');
  //list fieldnames
  for i:=0 to rs.Fields.count-1 do
    Write(IIF(i>0, ';') + rs.Fields[i].name);
  WriteLn();
  //list values
  while not rs.eof do
  begin
    for i:=0 to rs.Fields.count-1 do
      Write(IIF(i>0, ';') + rs.Fields[i].AsString);
    WriteLn();
    rs.MoveNext;
  end;
  //close recordset
  rs.Close;
  rs.Free;
  //close connection;
  cn.Close;
  cn.Free;
end.

Ich habe mich mal an das von mir schon mal vorgegebene Beispiel gehalten, wenn es unter Zeos genau so einfach ist steig ich vielleicht um.

Ich hab noch schnell die beiden Connectionstrings für MySQL und MSSQL hinzugefügt damit wäre ADO fertig.

[mschnell]

Und ja kein Datenbankhersteller hat interesse daran das man einfach auf eine andere Datenbank wechseln kann....

Das sollten sich die Anwender aber nicht gefallen lassen. Schließlich kann man inzwischen auch mit jedem Telefon ein Telefon eines anderen Herstellers anrufen.

Und des SQL-Standard gibt es schließlich genau zu diesem Zweck und er ist von diversen Organisationen abgesegnet.

-Michael

[hde]

Das sollten sich die Anwender aber nicht gefallen lassen. Schließlich kann man inzwischen auch mit jedem Telefon ein Telefon eines anderen Herstellers anrufen.

Und des SQL-Standard gibt es schließlich genau zu diesem Zweck und er ist von diversen Organisationen abgesegnet.

Sorry @mschnell, in welcher Welt leben Sie eigentlich?

Zigtausend Programmierer in aller Welt leben mit dem Wissen dass ein Umstieg von einer DB auf eine andere nun wirklich nicht sooo einfach ist, wie Sie sich das denken. Und hinter diesen ITlern steht die Markmacht vieler Weltkonzerne. Da können Sie ja mal Klage einreichen gegen Oracle, IBM und andere.

Bei SQL ist nur die Basis der Sprache genormt, aber jeder DB-Hersteller bemüht sich um sinnvolle individuelle Erweiterungen, die nun wirklich alles andere als kompatibel sind. Es gibt DBs, da ist nicht mal das Ergebnis einer where-Abfrage mit Jokern identisch zu anderen DBs.

Das mag traurig sein, ist aber so ..

Und deshalb gibt es Tools (wie Zeos, ODBC u.a.) die das etwas vereinfachen.

hde

[mschnell]

Das mag traurig sein, ist aber so ..
Und deshalb gibt es Tools (wie Zeos, ODBC u.a.) die das etwas vereinfachen.

Andere Kommunikations-Standards scheinen erfolgreicher zu sein als SQL (z.B. TCP/IP (Novels SPX/IPX und Microsofts "NetBIOS" sind ausgestorben), SMPT (Nove's "MHS" ist ausgestorben, ....)

Ist ja auch gut, dass es solche Tools wie ZEOS gibt, die die von den Weltkonzernen verpestete Welt ein wenig erträglicher machen. Trotzdem ist es interessant zu verstehen was sie tun und warum anstelle sie einfach nur "blind" anzuwenden.

Wie war das:
Man darf Gott nicht anhand dieser Welt beurteilen. Das war nur ein missglückter Versuch.
Aber was muss das für ein Meister sein, der sich solche Fehler leisten kann.

-Michael