Da der MySQL Connector wie auch viele anderen Connectoren die Schnittstellen IDatabase, IDataAdapter usw. vollständig implementiert haben sollten die Funktionen und Objekte fast 1:1 nutzbar sein.

ausserdem erben die DbData-Objekte alle von den allgemeinen DbData-Objekten, die in System.Data.Common im Framework enthalten sind. Diese Basisklassen unterstützen noch bischen mehr an Funktionalität wie die IDataBlabla-Interfaces.
Guck dir die Angelegenheit mal im ObjectBrowser an.

Nutzen tue ich das in meine DBExtensions - allgemeine Lösung der Daten-Persistierung via Datenbanken - deshalb sind die provider-unabhängig.

verwende typisierte Datasets, und gib die (typisierte) DataTable, die du konkret befüllen willst, beim Befüllen mit an.
Sonst erstellt der glaub ieine Table, wies ihm passt.

Schau dir im OB die System.Data.Common.DbDataAdapter.Fill-Überladungen an.

Und was hindert dich daran auf VS 2013 Community zu wechseln?

Dann bau das typisierte Dataset selbst, im Dataset-Designer.
Es muss allerdings 100% auf die Datenbank passen.

Dassis mühsam, aber meinen DbGenerator wirst du ja auch nicht verwenden wollen, weil du den Code nicht verstehst.
Weil DbGenerator dreht den Spieß um: Nicht mehr das Dataset wird aus der DB generiert, sondern die DB wird aus dem Dataset generiert.
Ergebnis dasselbe, nur in einem Dataset kann man ein Datenmodell viel besser anlegen als mit den MySql-Murkel-Tools.

jedenfalls am typisierten Dataset führt mittelfristig doch eh kein Weg vorbei.
Ohne typisierte Datenklassen eine auch nur leidlich ergonomische Oberfläche erstellen zu wollen - dabei kriegt man dochn Vogel!

programmatisch kann man kein typDataset bauen. Baus im Designer, meine ich.

ja - ist super!

Und dieses Datenmodell hast du ebenso auch in der Datenbank?

tut mir leid - das verstößt gegen grundlegende Regeln der Datenmodellierung.
Früher oder später wirst du das umbauen müssen, weil so vermurkste Datenmodelle fahren iwann gegen die Wand.

3030 und 3040 sind ja identisch - sowas gehört dann in eine gemeinsame Tabelle, und man würde eine zusätzliche Spalte machen, die aussagt, ob der Datensatz 3030 ist oder 3040.

Dasselbe Spiel mit 2121 und 2121C.

Ich predige ja unablässig, die Datenbank erstmal wegzulassen, und Datenmodellierung und Databinding erstmal ohne zu erlernen, und umzusetzen.
Nu haste das "Gschiss" - da wirste nun iwann Datenbank und Dataset korrigieren müssen, früher oder später, und früher ist besser als später.

guggemol "Vorbemerkung" in Daten laden und speichern

hirnwunde schrieb:

Das ist leider nur die halbe Wahrheit.
Sie sind vielleicht von den Datenfelden her identisch, aber es sind zwei unterschiedliche Bauteiltypen mit verschiedenen Abmaßen.

Ja - Datenmodellierung richtig anwenden!
Es fehlt eine Tabelle BauteilTyp, auf die von MessDaten verwiesen werden kann.
Damit ein Messdaten-Datensatz seinen BauteilTyp angeben kann.

Datenverarbeitungs-Vorraussetzungen - Punkt#5 - weil ohne die Theorie geht man inne Praxis unter.

naja - die Yoda-Grammatik hasteja schoma drauf.

Von allen Kultur-Errungenschaften des SternenKrieges die wertvollstes es ist ich finde.

Ganz sicher bin ich nicht, ob alle 4 in eine zu packen, möglich ist.
Da wäre ich vmtl. nichtmal sicher, wenn ich dein Teil komplett selbst entworfen hätte - sowas stellt sich manchmal erst noch im Verlauf heraus.
Wie gesagt und wie man sieht: Datenmodelle ändern sich während einer Entwicklung immer wieder mal, und deshalb ists keine gute Idee, von Anfang an immer eine DB mit durchschleppen zu wollen.

Aber wenns dir zunächstmal möglich erscheint, würde ich sehr empfehlen, alle 4 zusammenzufassen, und bei den Spalten, die von bestimmten Bauteilgruppen nicht benutzt werden, Defaultwerte einrichten und AllowDbNull.False festlegen.
Weil wenn Nullwerte erlaubt sind, muss man bei jedem Zugriff sehr umständlich auf IsDbNull testen - das spart man sich, wenn man sie nicht erlaubt.

Aber es fehlt immer noch die übergeordnete Tabelle TXLCode, auf die verwiesen wird.
TXLCode kann nicht einfach eine (String?) Spalte sein, denn es gibt unendlich viele verschiedene Strings.
In deinem Datenmodell sind aber nur eine sehr endliche Anzahl an TXLCodes zulässig, ich glaube genau 4 Stück, um genau zu sein.