wenn nur eine uhrzeit angegeben wird, dann geht die DB aber vom kleinstmöglichen Datum aus, d.i. glaub der 1.1.1900 (oder wars der 1.1.1970?). Egal, jdfs. mit Sicherheit nicht das richtige Datum.

Dein Textbox-Problem wäre am besten zu Lösen durch Verwendung eines DateTimePickers. Der kann nicht leer sein.
Oder sonstwie dafür sorgen, dass die Textbox nicht leer ist.

Databinding könnte auch dieses Prob lösen.

bei databinding soll man nie den Wert aus dem Control holen, sondern aus den Daten - das Control ist da ja nur drangebunden.

Das liefe auf einen ziemlichen Umbau deines Monster-Sqls hinaus, denn die Daten sind ja bereits DataTimes und müssen also nicht konvertiert werden.

Noch günstiger wären typisierte DataTables als Daten, denn da sagt man dem DataAdapter einfach "UpdateDuDas!" - und das Thema ist abgehandelt.

Achja - DbParameter verwenden sprach ich ja erst neulich an.
Wenn ich mcih recht erinnere, wolltest du dich damit beschäftigen.

Ähm - falls es dir damit ernst ist, kannstejetzt eiglich hiermit aufhören, denn wenn du dich wirklich damit beschäftigst, wirst du diesen Ansatz ziemlich komplett übern Haufen werfen - also wozu jetzt hier vertane Arbeit reinstecken?

Tja, ich hab nur Samples, die von einer funktionierenden Datenbank ausgehen, also einer, in der ein Datenmodell angelegt ist, was aufgeht.

Bei deiner DB bezweifel ich sehr, dass die funktionsfähig modelliert ist.

Kannst du mir dein Datenmodell auseinandersetzen?

ein screenshot von deim typisierten Dataset würde dein Datenmodell gut beschreiben.

oder halt erklären, welche Tabellen in deiner DB sind, und wie die miteinander verknüpft sind, und warum.

Romed schrieb:

Was meinst du genau damit mit auseinandersetzten???

Also hier findet zB. eine Auseinandersetzung mittm Datenmodell statt: [VB 2010] Nach erfolgter Auswahl die Auswahlliste in einer DataGridViewComboBox ändern

ich weiß auch nicht, warum das immer so schwierig ist - es geht im Grunde nur darum, ziemlich banale Zusammenhänge ganz konkret zu beschreiben. Einfach sich verständlich ausdrücken.
Eine Schwierigkeit dabei scheint zu sein, wirklich die treffenden Bezeichnungen zu finden, und nicht rumzuabstrahieren, wo man konkret bleiben kann und sollte.

Äh - du hast komplett das Thema gewechselt - ist die Frage nach der Datenmodellierung jetzt für dich erledigt?

Weil dann ist für mich der Thread erledigt, weil kann nix bei rauskommen.

hängs doch an

glaub auch - sorry

Screenshot - Verknüpfungen der Tables - anhängen

welche der 3 Elemente sind dir unklar?

ich empfehle übrigens, DB-Anwendungen immmer erst ohne DB zu entwickeln - DatasetOnly.

Änderungen am Modell sind schneller zu handhaben, und viiiele Fehlerquellen, die sehr aufhalten können, spart man sich für später auf, wenn man besser durchblickt.

jo, jetzt musstes nurnoch erklären.

also Kontakte scheint mir eine falsche Bezeichnung - es sind Mitarbeiter (oder?).

Dann sehe kurse, teilnehmer, und - KundenDaten??

sind die Teilnehmer nicht die Kunden?


Insgesamt empfehle ich, unnütze Prefixe weglassen (inne DB sind alle Prefixe unnütz), Tabellen als Singular bezeichnen, groß geschrieben.
PrimKey einer Tabelle heißt (fast) immer ID, ForeignKey heißt immer "AndereTabelleID".

Das issn ganz einheitliches System, mit dem man sich gut orientieren kann, und woraus sich später auch leidlich erträgliche CodeNamen generieren.


Aber ich hab kein Plan, wozu der Stundenzettel gut sein soll, und v.a. was das ganze Zeug dadrin soll.
Mir scheint "Dienst" könnte eine treffende Bezeichnung sein.
Weil es sind ja keine Stundenzettel in der Tabelle, sondern Dienste.
Und sicherlich gibtes Dienste verschiedener Art, das scheint mir in tbldienstschichten angedeutet. Auch hier vernünftig benamen: "DientsArt".
(wenn ich denn den Sinn dieser Tabellen ühaupt richtig erfasst habe)
Und natürlich muß der konkrete Dienst per ForeignKey auf eine DienstArt verweisen, und dann kann man glaub schon reihenweise Spalten ausmisten, die ja bereits in DienstArt definiert sind.

soweit erstmal.