OliverSte schrieb:

Das kann doch nur ein Traum sein oder? Ist das wirklich schon alles?

Tja, ich denke schon.

OliverSte schrieb:

Also die Button feuern keine Events.

Woran das liegt habich keine Ahnung.
Der Code sieht korrekt aus, vorrausgesetzt Class Telefonbuch ist ein Form, und bLaden, bSpeichern sind Buttons darauf, die man zB auch im Form-Designer dort sehen kann.

OliverSte schrieb:

In deinem SqlCe Beispiel instanziierst du die Variable _Persistance in der Sub New() nach InitializeComponent(). Wann wird das aufgerufen?

Na, wenn ein Konstruktor eben aufgerufen wird. Also wenn das Form erstellt wird.
Aber setz doch einen Haltepunkt rein, und sie selbst nach, wann das aufgerufen wird.

Gut wäre auch, den Code zu sehen, der nicht funktioniert. So ist das alles nur Schwafel ins Blaue.

InitializeComponent() wird in VB irgendwie versteckt ausgeführt.
Stell oben im Projekt-Explorer ein, dass dir alle Dateien angezeigt werden, da gibt es ein Symbol auf das du dazu klicken musst.
Wenn du dann im Telefonbuch.Designer.vb die Zeile
<System.Diagnostics.DebuggerStepThrough()>
vor der Zeile Private Sub InitializeComponent()
auskommentierst und in der Sub einen Haltepunkt setzt, siehst du, dass Telefonbuch_Load direkt danach ausgeführt wird.

Wenn du InitializeComponent() selbst kontrolliert ausführen willst, dann kopiere den folgenden Code und füge ihn in Telefonbuch.vb über Telefonbuch_Load ein:

(Quelle: stackoverflow.com/questions/18…component-is-not-declared)

Unmittelbar unter InitializeComponent() kannst du jetzt deine eigenen Inititalisierungen durchführen.

OliverSte schrieb:

Wenn ich nun das Ereignis Load folgendermaßen...

Nee - so nicht.
InitializeComponents() muss im Konstruktor aufgerufen werden - nicht im Form_Load.
Oder sonst irgendwo anders.
Oder - wenn du keinen Konstruktor brauchst, lass ihn weg, dann macht vb.net das unsichtbar im Hintergrund.

Aber eben auch @Dksksms Empfehlung: Entferne das depperte DebuggerStepThrough-Attribut von InitializeComponents() - dann kannst du besser debuggen.

Ums verständlich zu machen:
InitializeComponents() initialisiert alle Controls, die auf dem Form zu sehen sind. Das muss so früh als irgend möglich passieren.
InitializeComponents() ist auch besonders interessant: Wenn du im Form-Designer Änderungen an deinen Controls vornimmst, werden diese Änderungen vom FormDesigner in ganz normalen vb.net-Code übersetzt - welcher nämlich in InitializeComponents() steht.
Spiel da mal ein bischen mit rum.

Ansonsten muss man mit Designer-Code höchst vorsichtig umgehen - am besten gar nicht.
DEr Code ist vom Gesichtspunkt der Wartbarkeit ziemlich miserabel, aber man kann ihn nicht verbessern, weil wenn du im Designer Wysiwyg irgendeine Kleinigkeit veränderst, generiert er die Datei neu, und deine Änderungen sind weg.
Eigentlich ein Zufall, dass der Designer es nicht überschreibt, wenn man das depperte DebuggerStepThrough-Attribut wegnimmt - da sind wir einfach froh und dankbar für.

naja, das neueste ist immer das beste.
Meine Helpers sind manchmal ungekürzt an iwelche Tuts drangehängt, die eigentlich was ganz anderes zum Thema haben.
Mit dene kann ich halt sehr schnell und sauber entwickeln.
Aber die ungekürzten Helpers können nie selbst Gegenstand eines Tuts sein, weil sie halt alles mögliche abdecken.
Ich bastel da auch immer wieder dran rum - die veralten also auch.

Hingegen so MiniHelpers konzentrieren sich auf das, was für das Tut nötig ist. Dann ist der Code nicht so viel und kann man auch verstehen, weil man ja auch sieht, wie er verwendet wird - das ist der Vorteil davon.
Das gehört dann schon eher zum Tut, und zeigt ja auch auf, wie man eine Solution aus mehreren Projekten zusammensetzen kann, und wie Helpers-Projekte besonders geeigneten Code dann auch in anderen Solutions bereitstellen können, ohne dass man mit Copy/Paste ein Wirrsal anrichtet oder gar dasselbe mehrfach entwickelt.

WinFormHelpers brauchste sowieso.

Zur Db-Persistierung neige ich eher zu DbPersistance.
Ist neuer und schlanker als DbExtensions.

OliverSte schrieb:

Nun müsste man mal sehen, wo welche Funktion beschrieben steht, dafür gibt es ja diverse Tutorials.

Ja, sorry, das ist ein Problem.
GeneralHelpers und WinformHelpers decken immens viel ab, aber eine systematische Dokumentation dazu gibt es nicht.
Wüsste ich nichtmal, wie eine solche aufbauen, dass man alles darin findet, und es gleichzeitig aber auch versteht.

Was man aber verstehen kann ist, dass Helpers-Bibliotheken teilweise aufeinander aufbauen:

• GeneralHelpers - deckt allgemeine Algorithmen und Klassen ab - benötigt keine Winforms.
  
• WinformHelpers - unterstützt die Arbeit mit Winforms-Steuerelementen - insbesondere Databinding rauf und runter.
  WinformHelpers benötigt einige Algorithmen und Klassen aus GeneralHelpers
  
• MiniHelpers und MySqlHelpers unterstützen das Ansprechen von MySql
  brauchen WinformHelpers und GeneralHelpers nicht.
  

Wenn man alle vier verwendet, so hat man ein paar Sachen sowohl in MiniHelpers als auch in GeneralHelpers - das wäre architektonisch nicht ganz sauber, und man sollte Dinge aus MiniHelpers entfernen, die es ebenso auch in GeneralHelpers schon gibt.
Oder halt damit leben - solange man sich nicht gut genug damit auskennt.

tja, weiss ich auch nicht.
Ich kenn mich nur bischen mit Access und MS-SqlServer aus. Da gibt es date-Datentypen, die mit .Net-DateTime kompatibel sind.
Ich kann mir eigentlich nicht vorstellen, dass MySql keinen solchen Datentyp anbietet.
string ist jdfs. denkbar ungeeignet - man will Datumse ja sortieren, und will mit ihnen rechnen.

Sind die Datentypen in der MySQL vorgegebenen?
Warum nicht im Dataset die gleichen Datentypen?

MrTrebron schrieb:

Sind die Datentypen in der MySQL vorgegebenen?

na, wohl nicht - es ist ja ein Testprojekt

MrTrebron schrieb:

Warum nicht im Dataset die gleichen Datentypen?

"Gleichen Datentyp" kann es ja nicht geben - Sql und .Net-Framework sind ja verschiedene Sprachen.
Es kann allenfalls kompatible Datentypen geben, und wie gesagt ich bin sicher, dass MySql auch (mindestens) einen Datentyp bereitstellt, der zu .Net-DateTime kompatibel ist.
Ob es ausserdem einen TimeSpan-kompatiblen MySql-Datentyp gibt weiss ich nicht - aber vlt gibts da ja Doku zu.

@OliverSte:

Im Dataset habe ich System.DateTime eingestellt.

Hmm - wenn man die Fehlermeldung ganz naiv liest, steht da aber was anderes

OliverSte schrieb:

Im Dataset habe ich System.DateTime eingestellt.

Das ist wohl das eigentliche Problem.
Weil ein Dataset sollte man besser nicht händisch so hinbosseln müssen, dasses zur DB passt.
Also entweder das Dataset aus der DB generieren, oder andersrum aus dem Dataset eine DB generieren.

Händisch es hinfummeln erfordert ziemlich genaue Kenntnisse, die kaum irgendwo dokumentiert sind, und es sind hunderte von Einstellungen zu tätigen, und jede mit eigener Fehler-Gefahr.

Aber gut - die Selbst-Bastelei ist nicht immer zu vermeiden - zB die zur Dataset-Generierung nötigen Datenbank-Connectoren aller Nicht-MS-Datenbank-Systeme sind zickig zu installieren.

OliverSte schrieb:

Der Datentyp im Dataset ist DateTime, in MySql TIME. Damit produziere ich die o.g. Fehlermeldung. Frag mich nicht, warum da was von TimeSpan steht, bzw. woher das kommt.

Brauch ich nicht - ich kanns mir denken:
Du hast nu selbst gelernt, dass MySql-TIME zu .Net-DateTime nicht kompatibel ist, sondern zu .Net-TimeSpan.
Der DataAdapter scheint dieser Kompatiblität entsprechend den TIME-Wert intern in einen Timespan zu lesen. In einem zweiten Schritt versucht er, den Timespan auf den im Dataset vorgegebenen Typ zu konvertieren: auf DateTime.
Dazu würde er - wenn es ginge - die IConvertible-Schnittstelle verwenden wollen.
Tja - dummerweise implementiert TimeSpan nicht IConvertible - ja, und genau das sagt die Fehlermeldung.
(Zur Info: Andere Dataset-Datentypen, wie String, DateTime, Double,... - die implementieren alle IConvertible - gucks dir im ObjectBrowser an.
Aber Timespan numa nicht.)

---

Ansonsten finde ich dein Datenmodell zwar funktional plausibel, aber vonne Benamung her doch gegen so einiges, was ich unbedingt als BestPractice empfehlen würde.
Nämlich Public Member werden in .Net gross geschrieben (Pascal-case, um genau zu sein)
Und Db-Tabellen sollte man singular benamen
Andernfalls erscheinen die einzelnen Datensätze darin plural benamt, und ein einzelner Datensatz ist numa nicht Plural.
gugge codeproject.com/Articles/10331…eginners#Model-Guidelines

Jo, dann nur noch die Spalte Termin.Termin. Das ist doch kein Termin, sondern da steht doch sicherlich nur das Datum des Termins drinne.
Dann sollte sie doch besser Datum heissen, odr?

Jo, prinzipiell kann man schon auch DefaultValues für DateTime und Timespan im Dataset eintragen.
Aber Date.ToDay oder Date.Now natürlich nicht, weil das sind ja keine Konstanten.