Klar. Und was macht es auf Linux und Mac ?MmVisual hat geschrieben:ZEOS nutzt immer eine DLL
Ok. Damit kann Zeos dann vermutlich auch Tebellen anlegen und solche erweiterten Features benutzen, die nicht Serer-Typ unabhängig gehen.MmVisual hat geschrieben:Die DLL wird je nach DB Typ dynamisch geladen.
Klar. Gibt es für alle relevanten Datenbanken diese DLLs für alle Betriebssysteme und Architekturen (z.B. Linux auf ARM) ? Auch für JET ? Wo kommen sie her ? Vom Hersteller der Datenbank-Server oder vom ZEOS Team ?MmVisual hat geschrieben:Linux/Mac haben natürlich auch Libraries, das sind die .so Dateien.
Geht das mit ZEOS ? Klar, aber die Parameters sind (vermutlich) nicht "SQL-Stadard" sondern Datenbank-Server--Hersteller-spezifisch.MmVisual hat geschrieben:Um Datenbanken und Tabellen an zu legen gibt es entsprechende SQL Befehle, das hat nichts mit ZEOS oder der DLL/SO zu tun.
z.B.:
CREATE DATABASE
CREATE TABLE
Einfach um SQL-Befehle unverändert per TCP/IP an einen (Client-Server) SQL Datenbank-Server zu übertragen (und "normale" Ergebnisse zu empfangen) brauche ich keine vom Datenbank-Server-Typ abhängige DLL/so. Da würde eine allgemeine Funktionalität, die für alle diese Datenbanken identisch ist, ausreichen (genau darum geht ja diese Diskussion). Für JET brauche ich natürlich immer eine DLL/so, um die SQL-Funktionalität auf dem "Flat-File" überhaupt erst einmal zu erzeugen.MmVisual hat geschrieben:Diese SQL Befehle werden der DLL übergeben und diese baut wie auch immer (z.B über TCP/IP) eine Verbindung direkt zum Datenbankserver auf.
Dafür müsste dann das Betriebssystem aber irgendeinen Mechanismus zur Verfügung stellen. Ich vermute, das ist "OLE-DB".MmVisual hat geschrieben:ZEOS erkennt in der Regel die Namen der DLL alleine...
Das ist vermutlich mindestens dann notwendig, wenn mehrere "Konnektoren" für verschiedene Datenbank-Server-Typen installiert sind. (Naja, in Windows ist "Jet" ja fast immer installiert...)MmVisual hat geschrieben:... sofern man die nicht ändert - Ansonsten hat die TZConnection auch einen Parameter "LibraryLocation" mit dem man den Pfad/Dateiname auch manuell angeben kann.
Es geht also auch ohne ADO und ODBC !?!?! Wo kommen dann die besagten DLLs her ? Die müssen ja eine genormte und dokumentierte Schnittstelle haben, die ZEOS kennt (außer ZEOS hat den Code für 735 verschiedene "DLLs" ausprogrammiert). Das Ding müsste ja irgendeinen Namen haben ?!?!? ("ADO", "ODBC" und "OLE-DB" hatten wir schon, gibt es noch einen vierten Begriff, der dann eindeutig die Schnittstelle zur Datenbank-Zugriffs-DLL benennt , die ZEOS verwende t ? )MmVisual hat geschrieben:Bei ADO oder ODBC müssen extra noch Einstellungen im Betriebssystem gemacht werden und für Linux ist das mehr oder weniger nur als Krücke verfügbar.
(...sofern das kein "common Standard" SQL-Befehl ist.) Dann verstehe ich nicht, wozu ADO denn im Endeffekt gut ist (außer um das Programm langsamer zu machenMmVisual hat geschrieben:Auch wenn man ADO verwendet und unterschiedliche SQL Server unterstützen möchte, so muss man dennoch entsprechend dem Server auch die SQL Syntax schicken.
) .Das ist mir schon klar. Das ist eben kein "common Standard" SQL-Befehl. Tabellen umbenennen geht u.U. in manchen Datenbanken überhaupt nicht.MmVisual hat geschrieben:... um eine Tabellenspalte um zu benennen, für MySQL, SQLite und MsSQL, dann weißt Du was ich meine.
Will ich im Moment gar nicht. Ich will nur das Prinzip verstehen.MmVisual hat geschrieben:Wenn Du Datenbanken in Lazarus ansprechen willst,...
Eine beeindruckende Liste.MmVisual hat geschrieben:dann kann ZEOS diese: ...
Klar. Aber da ja bestimmt kein Hersteller mit der Anfrage "Mach mir eine ZEOS DLL" anfangen kann, was für eine DLL/so ist das dann ?MmVisual hat geschrieben:Welche davon jetzt mit welchem Betriebssystem funktionieren ist erst mal davon abhängig ob die Firma/Entwickler der Datenbank für dieses Betriebssystem/Prozessor Architektur auch eine DLL/SO bereit stellt.
Es gibt aber eine Anleitung: http://zeos.firmos.at/kb.php?mode=article&k=10 . Als irgendwer scheint sowas zu tun.... Es sieht da so aus als müsse ZEOS tatsächlich dezidierten Code für jede einzelne verwendbare Datenbank bereits in die Library eingebaut haben und ein eventuelle gemeinsame "Normierung" der verschiedenen DLLs/so nicht explizit berücksichtigt wird.MmVisual hat geschrieben:Machen die das nicht, dann wird auch das ZEOS Team das nicht machen.
... sondern besserMmVisual hat geschrieben:Das ganze hat mit ADO oder ODBC nichts zu tun.
. Das hatte ich aus Deinen bisherigen Ausführungen bereits verstanden. Und wie bereits gefragt: was ist denn dann ? Code: Alles auswählen
program ADOTest;
{$APPTYPE CONSOLE}
{$mode objfpc}{$H+}
uses Classes, SysUtils, ComObj, Variants;
function IIF(b: boolean; sTrue: string; sFalse: string = ''): string;
begin if b then result := sTrue else result := sFalse; end;
const
adOpenForwardOnly = $00000000;
adLockReadOnly = $00000001;
var
cn, rs: OleVariant;
i:integer;
begin
//connect db
cn := CreateOleObject('ADODB.Connection');
cn.Open('Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\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 := CreateOleObject('ADODB.Recordset');
rs.Open('SELECT * FROM tblTable', cn, adOpenForwardOnly, adLockReadOnly);
//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, ';') + VarToStr(rs.Fields[i].Value));
WriteLn();
rs.MoveNext;
end;
//close recordset
rs.Close;
rs := unassigned;
//close connection;
cn.Close;
cn := unassigned;
end.
!Das verstehe ich und werde es mir merkenMmVisual hat geschrieben:Was verstehst Du denn jetzt nicht? Dass ich abrate von JET / ADO / ODBC und eine andere DB empfehle?
Da scheint aber eine ganze Menge Hersteller-unabhänging genormt und verwendbar zu sein:hde hat geschrieben:Nur nebenbei: SQL ist zwar bedingt genormt, aber es gibt trotzdem Abweichungen.
Ah, so heißt das Ding also ! (ich gebe zu dass ich davon noch nie gehört habe.)hde hat geschrieben:XDEV3 liefert deshalb eine eigene Schicht mit die auch dies vereinheitlicht.
Sorry, ich möchte Dir auch nicht zu nahe treten aber wir sprechen alle von Zugriffen auf Datenbanken, wir haben nur andere Kenntnisstände, es sind wohl immer einige die etwas mehr und einige die etwas weniger wissen, das ist nun mal so in einem Forum. Und genau das ist der Grund für ein Forum!hde hat geschrieben:Sorry, ich will keinem zu Nahe treten, aber ich hab hier das Gefühl, es reden viele über Datenbanken die über Datenbanken genau sowenig wissen, wie Milchkühe übers Eierlegen.
Das macht man als C++ Entwickler auch nur wenn man blöd ist, dann ist man ja abhängig von einer Datenbank! Außerdem gibt es kaum eine API die nicht auch in Pascal anzusprechen ist, oft ist sogar nur ein einfacher Import erforderlich oder eine Konvertierung der C-Header-Files und man muss nicht einmal selbst Hand anlegen.hde hat geschrieben:Jeder Datenbankhersteller liefert eine API/DLL mit, über die direkt von der jeweiligen Programmsprache aus auf die Datenbank zugegriffen werden kann, aber nicht so einfach mit Pascal sondern mit C++. Wer in C++ ein Prog schreibt für eine spezielle Datenbank braucht weder ODBC noch ADO und auch nicht Zeos. Man bindet einfach die DLL ein und greift direkt zu.
Wie ich auch schon erwähnt habe benötigt man für ADO nur einen Connectionstring die Benutzung des ODBC-Administrator ist nicht erforderlich. Von ADO hast Du wohl keine Ahnung und mein Beispiel enthält alles für einen Zugriff (CSV-Export), keine einzige Datenbank-Komponente ist unter Pascal erforderlich nur (Windows, ActiveX, Classes, Variants).hde hat geschrieben:Viele aber nicht alle Hersteller liefern auch ODBC-Treiber mit, die den Zugriff weitgehend vereinfachen, aber nur für Windows und es erfordert Einstellungen im OS per ODBC-Administrator auf jedem Client der zugreifen soll. ADO ist etwas ähnliches. Man baucht aber dann den Zugriff von PAscal auf ODBC usw. also Zeos, die Lazarus-Tools oder de BDE bei Delphi.
Zeos ist sicher eine Tolle Sache ich habe mir die Sourcen gerade mal angesehen und nach ca. 5Minuten wusste ich schon, was ich für Dich noch einmal wiederhole falls Du es überlesen hast, Zeos nutzt wohl auch die ADO Schnittstelle, die Implementierung erinnert mich ein Wenig an die von Delphi. (siehe Verzeichnis /src/dbc/)hde hat geschrieben:Zeos bietet für alle Datenbanken die MmVisual genannt hat den direkten Zugriff von Lazarus aus auf die jeweilige API/DLL des Datenbankhersteller und liefert tatsächlich für jede dieser Datenbanken Anpassungen mit, außerdem für verschiedene Betriebssysteme und codiert gleichzeitig die diversen Codes um (UTF8, usw.). Auf den Clients sind KEINE Einstellung im OS notwenig, der Zugriff ist schnell und so direkt wie es möglich ist.
hde
Na dann viel Spaß mit ADO / OLE Objekten.
Verein
Links
Suche