dbcomponenten nutzen oder manuell handeln?

[khh]

hallo zusammen,
ich habe eine tabelle mit ca. 10 1:N Beziehungen und 2 N:M Beziehungen.
Lässt sich das mit Hilfe der Datenbankkompoenten darstellen und auch bearbeiten, oder sollte ich das lieber von Hand umsetzen.
Ideal wäre es natürlich, wenn die Daten mit Hilfe des TDBnavigator "verwaltet" werden könnten.
Ich weiss aber im Moment nicht, wie ich die Tabellen mit Hilfe der Dtenbankkomponenten miteinander verknüpfen kann.
Gibts dazu ein Tutorial?


Danke Gruss KH

[Sherlock]

Unabhängig von den Rahmenbedingungen wäre ich für Komponenten. Manueller Zugriff auf eine Datenbank ist doch vergleichbar mit der Neuerfindung des Rades.

Edit: Die Tabellen sind doch verknüpft. Was hat Dein Programm noch damit zu tun?

Sherlock

[khh]

heisst, die Komponenten "erkennen" die entsprecheneden Verknüpfungen in der DB?

[Sherlock]

Was erwartest Du eigentlich?
Ich erwarte von dB-Komponenten, daß ich auf die Datenbank zugreifen kann. Ich kann Selects schreiben, die dann in DataSets abgelegt werden, an die wiederum eine DataSource gehängt werden kann. Diese DataSource schließlich kann als Quelle für DBsensitive visuelle Komponenten verwendet werden. Welche Struktur die DB dabei hat, spielt dabei eine untergeordnete Rolle.

Ein Einführungskurs: http://delphi.about.com/od/database/...secourse_2.htm

Sherlock

[khh]

Zitat von Sherlock:

Was erwartest Du eigentlich?
Ich erwarte von dB-Komponenten, daß ich auf die Datenbank zugreifen kann. Ich kann Selects schreiben, die dann in DataSets abgelegt werden, an die wiederum eine DataSource gehängt werden kann. Diese DataSource schließlich kann als Quelle für DBsensitive visuelle Komponenten verwendet werden. Welche Struktur die DB dabei hat, spielt dabei eine untergeordnete Rolle.

Ein Einführungskurs: http://delphi.about.com/od/database/...secourse_2.htm

Sherlock

ich danke dir

[nahpets]

Hallo,

schau Dir mal die Attribute MasterSource und MasterFields von TTable oder TAdoTable an. Wenn Du die zwischen unterschiedlichen Komponenten dieses Typs richtig verknüpfts, solltest Du in den Anzeigekomponenten immer die gewünschte Master-Detail-Beziehung erhalten. D. h.: Du siehst im DBGrid für ein Detail nur die Sätze, die zum aktuell ausgewählten Master gehören. Wanderst Du per DBNavigator durch den Master, so wird die Anzeige in den Detail-DBGrids entsprechend aktualisiert. Das geht auch noch, wenn Du einen Master und mehrere Details hast und die Details wiederum Master von weiteren Details sind, also sowas in der Form 1:n:m. Und das dürfte doch das sein, was Du möchtest?

[joachimd]

Zitat von nahpets:

schau Dir mal die Attribute MasterSource und MasterFields von TTable oder TAdoTable an

kleine Anmerkung von mir dazu: Ich verwende so gut wie niemals diese Eigenschaften und setzte die Filter der Details lieber in einem Timer, der vom AfterScroll des Masters gefeuert wird.
Nachteile von MasterSource:
- die Detail-Datenmenge muss den richtigen Index anliegen haben
- es werden immer die kompletten Details geladen, was bei einem schnellen durchscrollen durch den Master unendlich langsam wird
Vorteile:
- bei einem Insert werden die Verknüpfungsfelder des Details schon richtig ausgefüllt

[khh]

Zitat von nahpets:

Hallo,

schau Dir mal die Attribute MasterSource und MasterFields von TTable oder TAdoTable an. Wenn Du die zwischen unterschiedlichen Komponenten dieses Typs richtig verknüpfts, solltest Du in den Anzeigekomponenten immer die gewünschte Master-Detail-Beziehung erhalten. D. h.: Du siehst im DBGrid für ein Detail nur die Sätze, die zum aktuell ausgewählten Master gehören. Wanderst Du per DBNavigator durch den Master, so wird die Anzeige in den Detail-DBGrids entsprechend aktualisiert. Das geht auch noch, wenn Du einen Master und mehrere Details hast und die Details wiederum Master von weiteren Details sind, also sowas in der Form 1:n:m. Und das dürfte doch das sein, was Du möchtest?

genau das brauche ich,

ich hatte keine table dazwischen geschaltet sondern nur querys und datasources

ich danke euch


Gruss KH