ich hab mal den clsXmlManager und clsDateManager rausgeworfen, und stattdessen die Load/Save-Business-Logik im typDataset angelegt.

War ja ziemlich unschlau: du hattest zwar ein typisiertes Dataset, hast es aber garnet verwendet - und stattdessen iwas komisches in den XmlManager hineingemurxt.

Wie gesagt: Ist jetzt alles weg, und du kannst dein typDataset anfangen zu verwenden.
Wichtiges Prinzip: Niemals zur Laufzeit DataTables erstellen, und DataSources zuweisen. Das soll alles immer so bleiben, wie's im Designer eingerichtet wurde.
Wenn du Daten neu laden willst, dann kannste die alten löschen - mit .Clear, und dann die Tabellen neu befüllen.
Also die Tabellen, die im typDataset vorhanden sind, leeren und befüllen - nicht versuchen, "einfach" neue, andere, zu nehmen.

Das erste was mir auffiel, die "alten" XML-Dateien werden nicht eingelesen.

ja, das typDataset speichert sich mit etwas anderem Xml ab als dein selbstgebasteltes untypisiertes.
Wenn du den alten Kram erhalten willst, kannste die Dateien mit Notepad++ - Textersatz aufs neue Format umstellen.

Amelie schrieb:

1.) Brauche ich eigentlich das 2te DT "WeatherYear" für die Berechnungen?

Das musst du doch wissen.
ich hab jdfs. nix gesehen, wozu das gebraucht würde.
Und vom Datenmodell her ist das eh ein Riesen-Fehler, eine zweite Tabelle zu bauen, genau wie die erste, nur unter anderem Namen.

Amelie schrieb:

2.) Mein Versuch mit den Duchschnittsberechnungen klappt nicht so.. Wo steckt da mein Fehler?

Weiss nicht - hab ich nicht geguckt, und guck ich erstmal auch nicht.
Wäre auch glaub ein neuer Forum-Thread, wo du dieses Problem ühaupt nachvollziehbar erläuterst.

Amelie schrieb:

mal reindenken

Jo, das wär wichtig.
Insbesondere, wie ich die BL in einer Partialen Klasse des typDatasets angelegt hab, das dürfte dir neu sein.
Und dieser Ansatz ist noch enorm ausbaufähig. (Etwa Durchschnittsberechnungen sind auch business-Logik)

Amelie schrieb:

Ja steige da noch nicht so richtig durch

naja. gugge post#2, also es sind lumpige 29 Zeilen.
Bzw zwei Public Methoden, nämlich LoadXml() und SaveXml().
Und eine Private Methode namens GenerateMonth()
Also zumindest was da passiert müsste doch sonnenklar sein: Speichern und Laden, und wenn bei letzterem eine Datei noch nicht vorhanden, dann eben Generieren.

Richtig. Das hast Du übrigens in jedem VB.NET-Projekt. Du hast anfangs Deine Datei Form1.VB mit Public Class Form1 und Du hast die Form1.Designer.VB mit Partial Class Form1.
Ich verwende solch eine Aufteilung pro Klasse mit noch viel mehr Dateien, um eine Übersicht über verschiedene Vorgänge zu behalten. Teilweise habe ich bis zu 7 Dateien pro Klasse - wenn nichts spezielles dazukommt.

Zu post#8: Jo, man kann mit partialen Klassen auch Code-Strukturierung betreiben - ist zB eine gute Alternative für die mir verhassten Regions.

---

Aber unverzichtbar ist dieses MIttel, wenn mit Designern gearbeitet wird, wie dem Form-Designer.
Und der Dataset-Designer ist auch so einer, und ist ein echtes Monstrum.
Der generiert nicht nur eine Partiale Klasse für das Dataset selbst, sondern für jede enthaltene Tabelle jeweils zwei weitere partiale Klassen: eine Klasse für die Table, eine Klasse für die TableRow.

Dieses System generierter Klassen ist die OOP-Darstellung des im Dataset formulierten Datenmodells.
Und alle diese partialen Klassen kann man mit eigenen partialen Klassen erweitern, und BusyiessLogik einbauen, dasses nur so kracht.
Daher schreibe ich so gut wie nie eigene BL-Klassen - ich erweiter immer nur die SteilVorlagen des Dataset-Designers.

---

---

@Amelie: Tja, du hast leider kein strukturiertes Datenmodell, sondern für jeden Monat eine Datei.
Das zwingt dich natürlich zu irrsinnig aufwändiger Dateiverarbeitungs-Logik.
Hättest du ein strukturiertes Datenmodell, wo in einem Dataset Monat und Wetter als verknüpfte Tabellen angelegt wären, dann würdest du dieses mit jeweils einem Befehl aus einer Datei laden oder speichern können.
Und du würdest lernen, wie man sowas nach Stand der Technik löst - oder zumindest dich darauf zubewegen.
Also: lerne Datenmodellierung (es ist nicht schwer). Tuts gibts sogar hier im Datenbank-Tut-Bereich

("Stand der Technik" ist natürlich ein schwer zu definierender Begriff.
Aber seine Daten in viele Dateien aufteilen ist sicherlich nicht Stand der Technik.)

was brauchst du beim Datenmodell noch Hilfe?
Du kannst doch Tabellen im TypDataset anlegen - musste nur tun.
Tutorials zu den Prinzipien der Datenmodellierung kennste ja - wäre vorteilhaft, die zu berücksichtigen.
Helfen kannich, wenndu es mal gemacht hast - die Regelverstösse sieht man in einem Screenshot ja sofort.

Jo, dein CodeWust entsteht ja vor allem deshalb, weil du kein Datenmodell hast.
Ich hab dir ja bereits 2 Klassen und ca. 300 Zeilen Code ersetzt duch vlt. 40 Zeilen, im Datenmodell angesiedelt.
Das ist aber nur der Anfang.
Deine ganzer Dateisystem-Zugriffskram kommt komplett weg, und deine Durchschnittsberechnungen schrumpeln auf DreiZeiler zusammen - wenn du auf eim durchdachten Datenmodelll aufbaust.

Grundsätzlich richtig!
Und sieht auch so aus, als ob du durchaus richtig Verknüpfungen siehst.
Das sind jdfs. die beiden Tables, die nötig sind, und die Relation (alias "Verknüpfung") dazwischen.
Und auch die richtige als Parent-Table bestimmt.

Aber einige handwerkliche Fehler:
Absolutely NoGo: deine Tables haben keinen Primärschlüssel. Steht in keinem meiner Tuts, wie unabdingbar PKs für eine DataTable sind?
Doch bestimmt - ohne das hätte ich das Tut "Grundlagen: Die relationale GrundIdee" doch garnet schreiben können.
Also deine Tables haben ganz richtig jeweils die Spalte ID, aber man muss per KontextMenu zusätzlich noch festlegen, dass diese Spalte der PK der Table ist (Der Dataset-Designer generiert anhand dieser Information wichtige Properties und Methoden).

Dann Benamung Benamung Benamung:

• Der dt-Prefix für die Tables ist üflüssig und störend. Prefixe haben nur sinn, wenn es verschiedene Prefixe gibt. In einem Dataset gibts aber nur DataTables, und wenn man vor jeder ein dt macht, wird dadurch keinerlei nützliche Information gegeben.
  
• Und Fremdschlüssel müssen so heissen wie die ParentTable, mit ID angehängt.
  Dann sieht man auf den ersten Blick, dass die PK-Spalte Month.ID verknüpft ist mit Weather.MonthID
  So wie es jetzt ist, kann ich nicht erkennen, welche die FK-Spalte ist, die auf Month.ID verweist.
  (Ich fürchte fast, du hast gar keine FK-Spalte hinzugefügt, sondern einfach irgendeine genommen.)

So, nu habich reingeguckt, äh - hast du irgendeines meiner Tuts konsultiert, in denen ich Prinzipien zur Datenmodellierung darlege?
Im Vier-Views-Videos kann man zugucken, da ists aber nicht schriftlich. Man muss halt genau zugucken.
Hier habichs auch schriftlich gemacht: codeproject.com/Articles/1033145/Databinding-for-Beginners, Abschnitt "Model-GuideLines"

An welchem Beispiel aus welchem Tut haste dich dabei orientiert?
Oder findest du darin auch nur ansatzweise wieder, was ich grad zuvor schrieb?

ErfinderDesRades schrieb:

Und Fremdschlüssel müssen so heissen wie die ParentTable, mit ID angehängt.
Dann sieht man auf den ersten Blick, dass die PK-Spalte Month.ID verknüpft ist mit (FK) Weather.MonthID

Den Dreh mit den ID-Spalten-Benennungen hast Du noch nicht raus. Ja, jede Tabelle sollte eine ID-Spalte haben. Aber die ID-Spalte der einen sollte nicht an die ID-Spalte der anderen gebunden werden. Vielleicht ist noch nicht ganz klar, was es mit denen auf sich hat. Wenn eine Tabellenzeile hinzukommt, Du also eine neue Weather-Tabellenzeile hinzufügst, bekommt diese Zeile automatisch eine einmalige ID, und zwar schaut das Programm nach, wie die "extremste" ID der bisherigen Zeilen ist und legt noch eine Schippe drauf. Wenn also 3 Zeilen da sind und die haben die IDs -1, -2, -4, dann wird die neue Zeile die ID -5 bekommen. Wenn Du diese ID aber an die ID-Spalte einer anderen Tabelle bindest, geht Dein Programm davon aus, dass die Weather-Zeile mit der ID -2 an den Month-Tabellen-Eintrag gebunden ist, der ebenfalls die ID -2 hat. Spätestens wenn es eine mehr Weather-Tabellenzeilen als Month-Tabellenzeilen gibt, ist eine Verknüpfung nicht mehr möglich, da irgendein Weather-Eintrag keine passende Month-Tabellenzeile mehr findet, da ja die ID der neuen Weatherzeile automatisch festgelegt wird.
Die Weather-ID darf also nicht an die Month-ID gebunden werden, sondern muss eine eigene Spalte namens MonthID haben. Und diese MonthID bindest Du an die ID der Month-Tabelle. Dann ist ganz einfach festlegbar, an welche Month-Tabellenzeile die neue Weather-Tabellenzeile gebunden werden soll, ohne dass es Probleme gibt. Und wie legt man das dann fest, wenn man eine neue Weatherzeile anlegt? Der Compiler verlangt automatisch die Monthzeile anzugeben, an die gebunden werden soll.

ABER!

In beiden Tabellen gibt es eine Monats- und eine Jahresspalte, je mit DateTime als Datentyp. Wozu brauchst Du dann überhaupt 2 Tabellen? Und warum müssen die genannten Spalten vom Typ DateTime sein?
Wäre es nicht sinnvoller, nur die Weather-Tabelle zu haben und Month* und Year* als Int32 zu definieren, sodass Du bei Month die Monatszahl und bei Year das Jahr als Zahl einträgst?
Das Speichern pro Monat wird dadurch nicht viel schwerer. Du kannst die gewünschten Zeilen später problemlos filtern, sie in eine temporäre DataTable schreiben und diese dann in einer XML speichern.

* inkonsistente Benennung der Spalten: Month und Year sind englische Begriffe, aber der Rest ist auf Deutsch.