D. Annies - Fr 14.08.09 08:55
Titel: Erklärung Datasource, Dataset

---

Hi, Delpher,

wer kann mir mal - jenseits von einem Tuto - die Komponenten Datasource / Datasource1 und Dataset / Dataset1 erklären? - Insbesondere, wann ich sie auf dem Formular brauche und wann nicht.

Ich weiß, das z.B. ein DBGrid die Zuweisung braucht:
DBGrid1.Datasource.Dataset := Tabelle1;

Aber damit habe ich ja nicht die obigen Komponenten explizit angesprochen.

Danke für Praktikerantworten,
Detlef

mkinzler - Fr 14.08.09 11:09

---

Eine TDataSource dient als Bindeglied zwischen den datensensitiven Komponenten und einem DataSet

Sinspin - Fr 14.08.09 11:11

---

Ein DataSet ist, wie die Delphi Hilfe es einem auch bereitwillig verrät, eine Schnittstelle zu einer tabellarischen Datenmenge. Also ist DataSet die Basisklasse jeder Tabelle oder Query.
Eine DataSource hingegen wird als Verteiler verwendet um die Daten in visuellen Komponenten darzustellen und ein DataSet als MasterSource einer Tabelle bereitstellen zu können. Wobei ein und dieselbe DataSource gleichzeitig für eine vis. Komponente als auch als MasterSource verwendet werden kann.

Willst du mit den Daten einer Tabelle arbeiten ohne sie visuell darzustellen brauchst du die DataSource nicht.
Die Reihenfolge in der eine visuelle Komponente Zugriff auf die Daten einer Tabelle nimmt ist immer:

• Vis. Komponente -> (hat) DataSource -> (hat) DataSet

Ich frage mich aber erhlich warum du hier lieber auf eine Antwort wartest anstatt einfach in der Delphi Hilfe zu lesen. Was anderes als das was da drinne steht können wir dir auch nicht sagen.

D. Annies - Fr 14.08.09 11:33

---

Hi, Stefan und Markus,
nun, es ist nicht so, dass ich zu faul bin, in der OH oder in Tuto's nachzusehen, aber folgendes ist für mich ein Unterschied:



Im obigen Codeteil (1) habe ich doch nur zwei Variable: aTable1 und DBGrid1.
Im unteren Codeteil (2) habe ich vier Variable: aTable1, Dataset1, Datasource1 und DBGrid1.

Deshalb frage ich nach.
Oder denke ich zu kompliziert?
Detlef

Robert.Wachtel - Fr 14.08.09 12:59

---

Wenn Du berücksichtigt, dass in Deinem ersten Beispiel Datasource eine Property des DBGrids darstellt und Dataset wiederum eine Property der Datasource, sind beide Beispiel nahezu identisch.

Ansonsten müsstest Du Dich noch einmal mit den Grundzügen der Objektorientierung auseinandersetzen.

D. Annies - Fr 14.08.09 13:05

---

Ok, und danke erstmal, Robert
Detlef :?

delfiphan - Fr 14.08.09 22:00

---

Die "vollständige" Verbindung ist ungefähr so:
(Vis. Komponente -> TDataLink) -> TDataSource -> TDataSet

Wobei mehrere DataSources einem DataSet zugewiesen werden können, und mehrere DataLinks einem DataSouce.

Diese indirekten Zuweisungen und Zwischenstufen bringen Vor- und Nachteile. Der eigentliche Grund ist, so sehe ich es zumindest, programmatischer Natur. In anderen Sprachen kann ich ein DataSet durchaus auch direkt mit einem datensensitiven Control verbinden.

Innerhalb von VCL wird ein TDataLink verwendet, um datensensitive Controls bereitstellen zu können. Stark vereinfacht ausgedrückt ist der Unterschied zwischen Edit und DBEdit eine TDataLink Instanz (und die Steuerung und Kommunikation damit). Eines der Gründe, wieso es die Zwischenstufen wohl braucht ist, dass Delphi pro Event nur ein Event-Handler erlaubt. Das ganze ähnelt etwas einem Publish/Subscribe. Wird ein TDataLink mit einem TDataSource verbunden, so registriert sich das TDataLink beim TDataSource und kriegt so alle nötigen Events mit. Dasselbe gilt zwischen TDataSet und TDataSource.

TDataSource pflegt nun eine Liste von verbundenen TDataLinks und reicht DataEvents an alle TDataLinks weiter, die sie selbst von TDataSet kriegt. Genauso pflegt TDataSet eine Liste von TDataSources.

Als Beispiel instanziert sich TDBEdit intern ein TFieldDataLink, und kann so exklusiv über die relevanten Events verfügen, ohne direkt Events bei TDataSource oder TDataSet überschreiben zu müssen. (TFieldDataLink macht natürlich noch ein bisschen mehr als nur Events anzubieten, es ist auch an ein bestimmtes Feld gebunden, etc.)

[OT]Leider bieten die Klassen um TDataSet am Schluss dann doch zu wenig, um komplexe datengebundene Controls damit effizient implementieren zu können. Beispielsweise ist (ironischerweise) das ganze nicht unbedingt geeignet, um damit ein komplexes Grid zu betreiben (obwohl TDataSet ja eben gerade für tabellarische Daten konzipiert ist). Für ein TDBGrid reicht es gerade noch. Sieht man sich jedoch die Sources zu DevExpress Grid an, so merkt man, dass die erstens eine interne Kopie des TDataSets halten müssen und bei jeder Änderung des aktiven Records über das gesamte TDataSet iteriert werden muss, um die relevante Änderung herausfiltern zu können. Und zwar deswegen, weil das Framework bei den Events, die durch TDataSource durchsickern nicht fein genug unterschieden wird, was jetzt ganz genau passiert ist. Andere komplexe Grids umgehen das Problem, in dem sie prinzipiell nur einen "Offlinemodus" bereitstellen, d.h. eigentlich nicht mehr Datengebunden sind. [/OT]

D. Annies - Sa 15.08.09 08:24

---

Hi, Delfiphan,
das ist ja sehr interessant!

Nun, mir ging auch so etwas im Kopf herum, ob ich auf die Komponenten Datasource1 und Dataset1 (z.B.) verzichten kann, oder ob sie existieren müssen - sonst würde es ja reichen, wenn eine Tabelle(nvariable) existiert.

Ich wollte genau auch so eine theoretische Erklärung haben und nicht etwas von der Art "probier's doch einfach aus", weil ich eigentlich im Vorwege wissen will, ob etwas geht oder nicht (und warum).

Danke dir,
Detlef

Robert.Wachtel - Sa 15.08.09 11:19

---

D. Annies hat folgendes geschrieben :

[...] Nun, mir ging auch so etwas im Kopf herum, ob ich auf die Komponenten Datasource1 und Dataset1 (z.B.) verzichten kann, oder ob sie existieren müssen - sonst würde es ja reichen, wenn eine Tabelle(nvariable) existiert. [...]

Bitte beherzige meinen Rat und beschäftige Dich nochmal mit den Grundlagen der objektorientierten Programmierung.

D. Annies - Sa 15.08.09 18:12

---

jo, mach ich.