Schau mal hier. Ist zwar ein Beispiel mit einem SQL Server aber es sollte eigentlich deine Fragen beantworten und ist einigermaßen leicht verständlich.

support.microsoft.com/kb/301248/de

MSDN schickt dich da schön auf den Holzweg. Mit dem Ansatz wirst du kilometerweise Coden für simpelste basic CRUD - Funktionalität.

Weiters hast du keine Chance, Databinding für dich arbeiten zu lassen, insbesondere bereits im Form-Designer. Folge: nochmal so viele Kilometer.

Gesamt-Folge: Eine eiglich unwartbare Anwendung.

guggemol "Datenbank in 10 Minuten" auf Movie-Tuts, wie man die vorhandenen Assistenten und Designer für sich ackern lassen kann.


Zur Eingangs-Frage: Es ist unsinnig, die Daten sortiert vonne DB abzurufen. Sortieren kann man ganz bequem im Gui. Überzeuge dich im SampleCode des Tuts, indem du auf die SpaltenHeader klickst.
Es ist auch unsinnig, Änderungen an die DB zu senden.
Änderungen werden im Dataset vollzogen, und sind dann logischerweise sofort auch im Gui sichtbar.
Zum persistieren bastel dir einen Speicher-Button, der alle Änderungen auf einmal in die DB schreibt. Das Dataset unterstützt dich dabei perfekt, denn es hat eine Änderungs-Verfolgung eingebaut, also es ist wirklich nicht mehr Code erforderlich, als im Tut gezeigt ( < 50 Zeilen )

Üblicherweise werden meine Hinweise verworfen, wohl wg Radikalität. Aber du kannst dich auch selbst davon überzeugen, dass mein Ansatz der von Microsoft so konzipierte ist - gugge Forms over Data Videos

Dass die Sortierung nicht geht, ist nicht sehr beglückend.

Dochdoch - die geht schon (also wenn du mit "die Sortierung" iein schnucklige Sql meinst).
Nur man braucht es nicht, weil im datengebundenen DatagridView eine Sortierung beliebiger Spalten bereits eingebaut ist (auf einen Spaltenheader klicken)

drschef schrieb:

"Die Projektmappendatei ...kann nicht konvertiert werden, da sie nicht bearbeitet werden kann ..."

Das kann man im DateiBrowser ändern.
Aus ieinem Grund werden manchmal gedownloadete Zips als ReadOnly entpackt. Rechtsklick auf den Ordner - "Eigenschaften", und Schreibschutz entfernen.

Auf der Site habich doch auch eine Code-Version für den neuen OleDB-Treiber eingestellt, weil Win7 mit dem ollen Kram nicht mehr klarkommt.
musste nochma gugge.

Und was man mittm Spaltenkopf sortiert, kann man auch im Designer an der BindingSource einstellen, etwa fertig.

drschef schrieb:

(Ich bin vielleicht ein wenig frustriert und blockiert, weil ich vor Jahren mit VB6 und Access ein Dutzend Anwendungen mit allen möglichen Besonderheiten programmiert habe. Und auf einmal steht man da wie ein dummer Junge und stolpert von einem Schlagloch ins andere.)

VB.Net ist zu Vb6-Umsteigern wirklich grausam.

Die Wahrheit ist nämlich: Es gibt keinen "Umstieg".
VB.Net ist von VB6 so weit entfernt ist wie Html von Java.

Ohne Übertreibung: Du mußt alles vergessen, was du je gedacht hattest, zu können. Weil es gibt nichts, gar nichts, was in vb.net nicht komplett anders gemacht wird (und viel besser) als in olle vb6.

Kompliment, übrigens!
Indem dir das selbst auffällt, hast du das vlt. schwierigste Lernhinderniss - na, "überwunden" ist übertrieben - aber doch lokalisiert.

Du glaubst nicht, wieviele vb.net-progger noch nach jahren immer noch im grunde vb6-code produzieren.
Und vb6-Code läuft leider noch, ist aber im VB.net-Kontext einfach grotten-schlecht.

Ich verstehe nicht genau was du da machst, aber mein Update führe ich bspw. immer so durch:

Versuche es bei DataSet.Clear vor dem Speichern noch mit DataSet.AcceptChanges()...MSDN

drschef schrieb:

Bei dem AcceptChanges kann man übrigens nachlesen, dass damit bestimmte Flags gelöscht werden, die wichtig für die Erkennung von jedweden Änderungen sind, so dass nachfolgende Updates ins Leere greifen.

Genau.

.AcceptChanges setzt die ÄnderungsVerfolgung des Datasets zurück auf .Unchanged. Daraus folgt, das bei einem anschließendem .Update nix an die DB gesendet wird, weil alle Datensätze ja "unchanged" sind.
.AcceptChanges sollteman als interne Methode betrachten, vorbehalten den DataAdaptern, die sie intern aufrufen, nachdem ein Update oder ein Select erfolgreich durchgeführt wurde.
Wenn also die geladenen Daten und die Datenbank-Daten tatsächlich in 100% Übereinstimmung sind.

Das ist eben das Problem an Dataset/DataTable.Clear. Das löscht nicht nur die Daten, sondern auch die Änderungsverfolgung, und folglich denkt Update, es sei nix zu tun.
Die Lösung ist bisserl komplex, nämlich alle DataRows aller DataTable einzeln löschen. Das kann man sehr performant umsetzen, indem man sich nur die TopLevel-DataTables vorknöpft, weil untergeordnete Datensätze werden ja automatisch durch die Löschweitergabe eliminiert.Ist im Grunde aber ganz abwegig - wer will denn komplett alle Daten, die geladen sind, endgültig und aus der Datenbank löschen?

Naja - wenn man eine bisherige Bearbeitung komplett verwirft, und die Daten frisch lädt, dann kann DataTable.Clear sinnvoll sein. Aber komplett: Dataset.Clear()?

Edit: Ich bin wirklich verwirrt, dass du dein Projekt auf auf der OriginalDatei mit 40000 Datensätzen arbeiten lässt, und dann ein ganzes Dataset löschen willst, also evtl. die ganze DB weghauen.
Was ich dir allerwärmstens empfehle: Backup machen!.

Bei die Datenbänkerei kann man sich wunnebar verdaddeln, auch in anneren Bereichen als nur dem DB-Zugriff. Da kann ein eine unbedachte Änderung oder auch Designer-Bug das ganze Projekt unrettbar verwüsten.
Nimm dir die Zeit, und bring SolutionExplorer bei dir ans Laufen, und überprüfe, dasser dein Projekt korrekt backupt.
Dann kannst du vor jeder grundlegenden Änderung mit einem Klick ein funktionsfähiges Backup erstellen.

Ich hätte noch radikalere Vorschläge, sowohl in Richtung leichter Einstieg: Datenbänkerei-Einstieg

als auch in Richtung komplexes Produktiv-Framework: DBExtensions
Beachte in letzterem auch meine vier Views - Theorie

Danke für deine Erklärung - habe die AcceptChanges-Methode erst jetzt im weiterführenden Sinn verstanden!
Wenn man deine DB-Extensions verwendet, hat man damit eigentlich nie damit etwas zu tun.

.AcceptChanges hat übrigens ein Brüderchen, was sich leichter nachvollziehbar verhält: .RejectChanges().
.AcceptChanges und .RejectChanges() implementieren glaub was inne Datenbänkerei unter "Transaktion" konzipiert ist, und dort redet man von "Commit und Rollback" - kannst die Begriffe ja auf Wiki nachlesen.
Oder kurz: Eine Transaktion fügt viele EinzelAktionen zu einer Einheit zusammen. Failt eine Einzelaktion, so wird der gesamte Cluster rückgängig gemacht, damit keine Daten-Inkonsistenzen in die DB gelangen.
Nu ist der AcceptChanges-Commit halt tückisch, weil er unabhängig vom wirklichen Commit (Senden der Änderungen an die DB) vollzogen werden kann.
Könnte man nun diskutieren, ob das ühaupt ein Commit ist, weil fürs System DB-Dataset ists kein Commit, aber Dataset-intern ist das ein Commit.
.RejectChanges (alias "Rollback") ist da gutmütiger, weil das entfernt die Änderungen aus dem Dataset, und dann ists ja korrekt, dass die Datarows den Status "UnChanged" haben, weil dann sind sie ja wieder kongruent zu den DB-Daten.