Hallo,

habe folgendes Problem: eine Datenbank, 2 Tabellen; Lead (mit KdNr und Ansp) und Ansprechpartner (mit KdNr und Ansp);

Ziel ist es eine Combobox zu machen, die den Ansprechpartner in der Leaddatenbank anzeigt, als Auswahl aber alle Ansprechpartner des Kunden zulassen.

Soweit so gut, es klappt eigentlich auch mit der Einschränkung, dass er immer dann wenn in der Leaddatenbank kein Eintrag ist (also keine Auswahl in dem Stammdaten) dann schreibt er mir den ersten Datensatz rein. Wie bringe ich der Combobox bei dass kein Eintrag in der Leaddatenbank einfach keine getroffene Auswahl ist?

so in die richtung geht das

hab beide Tabellen in einem Dataset, läßt sich das dann nicht über bindings lösen?

was ist ein "Lead"?

Ziel ist es eine Combobox zu machen, die den Ansprechpartner in der Leaddatenbank anzeigt, als Auswahl aber alle Ansprechpartner des Kunden zulassen.

"der" Ansprechpartner in der Leaddatenbank? gibt es darin nur einen?
"des Kunden"? Wo kommt denn nun der Kunde her? Gibts da noch weitere Tabellen?

Edit by ErfinderDesRades: --> unnötiges Vollzitat entfernt.

Ein Lead ist im Grunde eine Anfrage eines Kunden. Dem Lead ist nur ein Kundenansprechpartner zugeteilt. Ja es gibt eine Kundentabelle, dem wiederum die Kundenansprechpartner zugeordnet sind. Aber die anderen Tabellen sind in einem anderem Dataset.

Also Quasi DatasetKunde dort werden sozusagen die Kundenstammdaten inkl. Ansprechpartner erfaßt und Datasetlead, dort soll das Lead (du tust dich leichter wenn du Angebot nimmst, im Grunde das gleiche) bearbeitet werden.

In die Leadtabelle schreibe ich die Kd-Nr. aus der Kundentabelle rein als Bezug und die Ansprechpartnernummer als Bezug zum Ansprechpartner; In der Ansprechpartnertabelle steht logischerweise auch die Ansprechpartnernummer drin und auch die Kundennummer als Bezug zum Kunden.

Checkpoint schrieb:

Aber die anderen Tabellen sind in einem anderem Dataset.

Dassisn Fehldesign und somit ein Holzweg.
Die Daten gehören zusammen in ein Dataset, und dann kann man die Beziehungen zwischen den Tabellen auch für sich arbeiten lassen.

Insbesondere so Combobox-Geschichten lassen sich sehr einfach und zuverlässig lösen, wenn man mit einem typisierten Dataset arbeitet, in dem die Beziehungen auch abgebildet sind.

Ich hab jetzt deine Anforderung nicht verstanden, aber ein Standard-View wäre zB., mit einer Combo einen Kunde-Datensatz auszuwählen, mit der nächsten Combo einen LeadDatensatz dieses Kunden, und die dritte Combo würde den Ansprechpartner dieses Leads anzeigen, und über das DropDown könnte man diesen Ansprechpartner auch um-wählen.

gugge vier Views - den m:n - View.

Mit dem gleichem Dataset klappt das nicht (zumindest bekomme ich es nicht hin); Ich erklärs mal genauer:

Dataset1

Kundentabelle --> Kundenansprechpartnertabelle

Kundentabelle --> Vorgang --> Vorganglead (und dort einen Ansprechpartner aus Kundenansprechpartnertabelle hinterlegt)

Bei Dataset1 habe ich immer als zentrale Sicht die Kundennummer, alles andere ist quasi untergeordnet. (hoffe das ist verständlich)

Nächste Sichtweise soll ein Leadcenter sein, aber über alle Leads Kundenunabhängig. Also quasi eine Übersicht über die Anfragen. In der Anfrage hinterlegt soll sein ein Kundenansprechpartner. Über Dataset1 klappt das auch, wenn ich ein Lead aus dem Kunden raus anlege.

Deshalb mein Gedanke hier ein neues Dataset mit neuen Abhängigkeiten, nur wie schaffe ich eine richtige Abhängigkeit zwischen Lead und Ansprechpartner, in beiden habe ich die Kd.-Nr. und die Ansprechpartnernummer; Combobox soll einmal alle Ansprechpartner des Kunden zur Auswahl haben aber den bereits selektierten Auswählen.

Das Problem: Wenn ich die Leads mit Ansprechpartner mit Kd.-Nr. verbinde, dann nimmt er den ersten gefundenen Datensatz im Ansprechpartner und selekiert nicht den bereits in der Leadtabelle eingetragenen Ansprechpartner.

Du musst dich in die Prinzipien der Datenmodellierung einarbeiten, und dann klappt das wie am Schnürchen.

Dassis eigentlich nicht weiter kompliziert, es sind nur ein oder zwei Grundgedanken - gugge die relationale GrundIdee

Dann hast du auch eine definierte Sprache, mit der man kommunizieren kann.
Ich bin mir nämlich nicht sicher, was --> in deinem Datenmodell bedeutet.
Bei mir stellt '->' eine 1:n - relation dar, also die Beziehung einer Übergeordneten Tabelle zu einer untergeordneten.

Damit könnte ich dir folgendes kleines Datenmodell skizzieren:
Kunde->Lead
Ansprechpartner->Lead

oder die m:n-Relation noch klarer ausgedrückt:
Kunde->Lead<-Ansprechpartner

Son Datenmodell ist über die Vorstellung "zentrale Sicht" hinaus, man hat damit die verschiedensten Möglichkeiten, Sichten zu implementieren:

Eine deiner gewünschen Sichten ist vom Kunde auf den Lead zu kommen, und von dem auf den Ansprechpartner

Ebenso kannman was basteln, wo man vom Ansprechpartner auf den Lead kommt, und zum entsprechenden Kunden

Und ebenso kann man natürlich auch eine totale Sicht der Leads machen, von der man sowohl auf Ansprechpartner als auf Kunden kommen kann.

Aber nun führst du noch eine Tabelle Vorgang ein, und ich steh mit meinen Versuchen, dein Modell zu verstehen, wieder am Anfang.

Auf jeden Fall ist das ein Datenmodell, und gehört daher in ein Dataset.
Weil die Dinge, um die es da geht, stehen ja tatsächlich in Beziehung zueinander, und Aufgabe der datenmodellierung ist nix anneres, als die wirklichen Beziehungen der Dinge in ein Modell zu übertragen.

ErfinderDesRades schrieb:

Aber nun führst du noch eine Tabelle Vorgang ein, und ich steh mit meinen Versuchen, dein Modell zu verstehen, wieder am Anfang.

Die Tabelle "Vorgang" ist sozusagen die zentrale Sammelstelle für alle Vorgangsarten dem Kunden gegenüber (also z.B. Lead, Angebot, Auftrag, Notiz usw.)

Kunde --> Vorgang --> VorgangLead

In der Tabelle Vorgang habe ich ein Feld "Vorgangsart" und das bestimmt dann welche Tabelle die Detaildaten des Vorgangs enthält. Also als Beispiel steht da in der Vorgangsart "Lead" dann sind die Details in der VorgangLeadtabelle.

jo, son Datenmodell ist nicht möglich, soweit ich weiß.
Das würde ja bedeuten, in Vorgang existiert ein ForeignKey, der entweder auf einen Lead verweist, oder auf ein Angebot, oder auf sonstwas.
Das macht kein relationales Datenmodell mit, weder typDataset, noch die üblichen relationalen Datenbanksysteme (oh, es gibt ganz tolle neumodische Sachen! aber die haben womöglich ganz annere Schwachpunkte, und unterstützen bestimmt kein WinForms-Databinding)
Eine Relation definiert immer eine Abhängigkeit einer bestimmten Tabelle von einer bestimmten anneren.

Relational modellieren könnte man den Vorgang so, dasser sowohl auf einen Lead verweist, als auch auf ein Angebot, als auch auf sonstwas.
Dabei müsste man aber in Kauf nehmen, dass alle diese Verweise auf Null zeigen können, und nur einer es eben nicht tut, welcher dann anhand des Vorgangtyps zu identifizieren wäre.

Aber auch Databinding unterstützt sone Konstruktion nicht, man müsste also an diesem Punkt etwas frickeln.

ok...ich erklär es dir auch hier mal genauer.

Tabelle Vorgang hat VorgangID, ID, Vorgangsart, Vorgangsdatum, Vorgangsbetreff

Damit mache ich ein Datagridview, dass alle Vorgänge im Überblick zeigt;

Tabelle Lead hat LeadID, VorgangID, und weitere Daten

Die Verbindung zwischen Vorgang und VorgangLead ist die VorgangID die aber für den Benutzer unsichtbar bleibt.

Die LeadID schreibe ich in den Vorgang bei ID; D.h. im Vorgang habe ich eine Vorgangsart "LEAD" und eine ID nämlich die zurückgeschriebenen Leadnummer

Gleiches dann mit z.B. Angebot; Tabelle: AngebotID, VorgangID und weitere Daten

wieder in Vorgangtabelle dann: Vorgangsart "Angebot" und ID ist dann die zurückgeschriebene Angebotsnummer.

Im Endergebnis: Datagridview Vorgang; Enthalten verschiedene Vorgangsarten die wiederum auf verschiedene Vorgangstabellen verweisen, verbunden mir der unsichtbaren VorgangsID.

Ich hoffe das ist halbwegs verständlich.

Ja, habe ich glaub richtig verstanden.
Die Spalte Vorgang.ID soll eine Art ForeignKey sein auf unterschiedliche Tabellen.

"Eine Art ForeignKey" - das ist ja noch hinzukriegen - weil in eine normale Spalte kann man ja schreiben, was man will.
Du kannst für diese Multi-ForeignKey-Spalte aber keine Beziehung definieren - weder inne DB, noch im typDataset.

Inne DB hat das den Nachteil, dass keine Datenkonsistenz garantiert werden kann - also dass man da jeden Quatsch reinschreiben kann. Klingt kleinlich, aber sowas kann irgendwann irgendwo Fehler verursachen, die sogut wie unauffindbar sind.

Im typDataset hat das den Nachteil, dass keine DataRelation gesetzt werden kann. Damit entfällt für diese "Beziehung" die gesamte Unterstützung, die typDataset normalerweise für verknüpfte Tabellen bereitstellt, insbesondere die Möglichkeit, Databinding einzusetzen.

du meinst zwischen Vorgang und VorgangLead? Doch da hab ich eine Relation nämlich die VorgangsID und die Vorgangsart (sogar noch die Kd.-Nr. um die mit durchzuschreiben); Man kann ja auch mehrere Relationskriterien gleichzeitig definieren, so hab ich das zumindest verstanden.

Was die Eingaben betrifft, dass wird natürlich programmgesteuert gemacht ohne Usereingriff, sonst entsteht da Mist, da hast du Recht.

Du solltest dich wirklich ausführlich damit beschäftigen, mach lieber erstmal was einfacheres und brings zu laufen, ehe du dich in solche möglicherweise undurchführbaren Abenteuer stürzt.
Ich sag: Möglicherweise, denn möglicherweise ists auch möglich - aber sicher nicht ohne erhebliche Komplexität in die Anwendung zu bringen - und vlt. gehts auch wirklich garnet.

Dass du da eine Relation bereits hast, sehe ich auch, nur ist die ja gewissermaßen falsch herum. Also für annere Sichten ist die vlt. richtig rum, aber deine "Multi-Relation" ist davon garnet betroffen, und die ist das Problem.