Klasse wahlweise einbeziehen

strzata schrieb:

ds.ReadXmlSchema(Application.StartupPath & "\GevkoBQ\gevkobq.xsd")
nicht weglasse, sind die 47 Tabellen im ds drin.
Vielleicht braucht es das?

Wenn Dim test = ds.icd nun funktioniert, dann ok. Die Doku die sagt zwar das wäre überflüssig, aber vielleicht behebt das die Namenskonflikte, die wir uns duch das Copy&Paste reingeholt haben.

strzata schrieb:

Ich habe einen ICD-Schlüssel. Der kommt in der Tabelle "icd" kein Mal oder nur einmal pro Datensatz vor
Wenn er in der Tabelle "icd" gefunden wird, muss ich mit der in der Spalte "indikator_id" angegebenen ID in der Tabelle "indikator" suchen

Hier genau auf die Begrifflichkeiten achten.
Die Tabelle icd hat keine Primärschlüsselspalte angegeben. Deswegen bleibt nur LINQ-Suche.

Ok, ich hab es fast befürchtet. Du hast nu zwar den Designer und du hast Daten aber die Art und Weise wie wir beides hinbekommen haben passt noch nicht zusammen.
Deine Daten liegen in untypisierte Form vor und dein typisiertes DataSet ist leer.

strzata schrieb:

Und Copy&Paste hab ich nicht gemacht. Hab's im WindowsExplorer umbenannt. War das falsch?

Ne, also es war zumindest das, was ich meinte, nur hats nichts getaugt.

Was EdR gezeigt hat funktioniert einwandfrei, ich hab das Spiel jetzt nochmal am Stück durchgespielt, bei mir geht das. Nur die Datendatei kann ich nicht mehr prüfen, denn die hab ich ja nicht hier. Hier die Dia-Show

Doch doch, ist echt, haben wir doch schon gesehen. Du hast auch schon bei den vorigen Versuchen mal gesagt das DataSet wäre in der Toolbox erschienen.
Remember: Das Hinzufügen der xsd haben wir nur gemacht, damit du die Tabellen nicht selbst von Hand tippen musst und das klappt ja auch.

strzata schrieb:

SelektivVertraege-Komponenten ein bq rum. Sollte man das wegmachen?

Wüsste nicht warum. Edit: Weißt du was das ist? Vielleicht ist das das DataSet. Guck im DataSet-Designer Eigeschaftenfenster wie der Klassenname ist, vielleicht steht da "bq"

strzata schrieb:

Die Xml ist größer. Ich befürchte, die habe ich gar nicht im Projekt. Muss die nicht auch in den Solution-Ordner?

Ne, Daten müssen liegen dürfen, wo sie wollen, du gibst ja den Pfad im Code an. Du sagst im Application.StartUpPath, andere packen sowas in den AppData-Ordner von Windows.



Aber gut, es gibt natürlich auch weiterhin die Möglichkeit ohne Toolbox, du siehst es ist dasselbe in grün, nur der Name des DataSets hat sich geändert:
Das ist am Ende nichts anderes als was der Form-Designer bei sich hinschreibt, wenn du das Dingen aus der Toolbox ziehst. (Nur heißts dann Gevkobq1 statt DS)

strzata schrieb:

Liegt bestimmt an der xsd. Ist vielleicht gar kein echtes DataSet. Soll ich sie hier mal hochladen

das wär nett.
Ich bin auch höchst verwundert, dass du die überhaupt in einen DatasetDesigner laden kannst. Die Snippetse daraus, die ich bislang gesehen hab, sehen garnet wie Dataset-Xsd aus (aber ich lern gern mal was neues)

tja, das Ding ist nicht wirklich eine Dataset-Datei. Es konnte zwar DesignerCode generiert werden, der war aber ungültig, weil enthielt Relationen, die einander widersprechen.
Wenn ich das fixen wollte, hatter gar keinen DesignerCode mehr generiert.
Zur Info: Wenn kein DesignerCode generiert wird, dann gibts auch nicht die typisierten Tables, wo man so schön was reinladen kann und so.

Huhu!

Es ist mir nun doch noch gelungen, aus dem irregulären Dataset ein reguläres Dataset abzuleiten.
Und dann lese ich ins irreguläre Dataset ein, und fülle alle Rows um ins Reguläre.

Wenn das icd-Grid einen Datensatz anwählt, dann reagiert die angeschlossene BindingSource:


guck, das ist der relevante Ausschnitt aus dem Datenmodell:

ja, diese doofe CheckMenu.resx. Die muss man im Explorer aufsuchen, und in ihren Dateieigenschaften erlauben.
Sonst kompiliert winformHelpers nicht, und nix geht.

NOP heisst "No Operation" - das tut garnix. Mach ich manchmal hin, damit ich eine Befehlszeile hab, wo ich einen Haltepunkt setzen kann.
Natürlich ists erstmal kaputt, wenn die Struktur der Daten zu tiefgreifend geändert wird (etwa Umbenennung von Tables).
Dann muss man eine neue irreguläre .xsd erzeugen, daraus eine neu reguläre .xsd.
Der Code zum Umwandeln der irregulären in eine reguläre, und das Einlesen und Umfüllen beim Daten-Laden ist aber schoma da.

Aber dann muss man auch ein neues Form machen, weil die Databindings nicht mehr stimmen.

Für dich ist erstmal wichtig, die typisierte Datenverarbeitung zu erlernen, also so Sachen, wie sie im .CurrentChanged stattfinden.
Keine DataRows, DataTables, Dataviews, .DefaultView, .RowFilter etc. mehr! Also sowas wie in post#9 ist streng verboten.
Jede typDataRow kennt ihre ParentRows und ihre ChildRows - da gibt es generierte typisierte Methoden und Properties für.
Diese generierten Dinge, "Navigation-Member", folgen einem einheitlichen, leicht zu verstehenden Schema, sodass du im DatasetDesigner einfach guckst, wie heissen die verknüpften Tables, und dann weisste auch, wie die Methode oder Property heisst, die du brauchst, um von einem zum Andern zu kommen.
die gezeigte bsIcd_CurrentChanged() ist ein gutes Beispiel dafür, und in meine Tuts sind noch mehr Beispiele.

Das andere ist, Databinding einzusetzen.
Meine Anwendung präsentiert dir ja glaub 6 Tabellen, die alle miteinander zusammenhängen, also zu jedem gewählten icd (was immer das sein mag) kriegst du eine wahre Flut an Information.
Aber an Code sinds nur die gezeigten 7 Zeilen.
Alles andere wird durch die BindingSources gesteuert, die in richtiger Weise miteinander verknüpft sind (und daran hängen widerum die Datagridviews)

Ansonsten folgt die App bereits ansatzweise meinem "dataset-driven-Development"-Pattern:
GUI, Daten, Business-Logic und Helpers sind getrennt, oder zumindest leicht trennbar (das Laden müsste eiglich in dts.logic.vb - aber ist ja nur auf die Schnelle zusammengeschustert)
Und die Daten sind im Dataset organisiert, und davon gibt es nur ein einziges in der ganzen Anwendung (das immerhin ist schon in der .logic.vb).