Suchergebnisse

jo, machst du ganz richtig. Der Witz ist nur, dass beim EditVorgang das DataView in den EditMode geht. Welcher automatisch beendet wird, wenn der nächste Datensatz ausgewählt wird. Der EditMode ist eine Art Zwischenzustand, wo Änderungen erst noch vorgemerkt werden. So kann man am selben Datensatz mehrere Properties ändern, ohne dass es gleich ins Dataset geschrieben wird. Weiters kann man so die Bearbeitung eines ganzen Datensatzes auch insgesamt canceln. Jedenfalls - wenn du deine Bearbeitung …

DAs EndEdit schreibt die Daten ins Dataset. Nicht in die Datenbank. Dafür wäre ein DataAdapter zuständig.

zeilen #7,#8 sind natürlich ärgerlich. Also dass man die ganze Tabelle neu laden muss, und dabei auch die selektierte Zeile verliert, nur um einen popeligen Datensatz zuzufügen - ist doch grotesk. Aber ist leider unter den gegebenen Umständen nötig, weil die Datenbank den PrimKey des neuen Datensatzes neu festlegt - und diese Info muss zurücktransportiert werden. Abr wie gesagt, grotesk, dafür die ganze Tabelle neu einzulesen. Um also ernsthaft mit einer Datenbank zu arbeiten muss man andere Ges…

Zitat von Lupusverlach: „Mein Code da oben hat noch ein weitere Schwachstelle, wenn die Tabelle nach Name sortiert ist landen wir auf einen falschen Datensatz.“Ja, das ist logische Folge des ungünstigen Ansatzes, die Tabelle komplett neu zu laden. Mit der von mir gegebenen "Reizüberflutung" löst sich das in Luft auf - weil da wird die Tabelle nicht neugeladen für ein popeliges Insert. Willst du wirklich von nun an und in Ewigkeit Datenbank-Anwendungen entwickeln, die bei jedem Insert die Tabelle…

Zitat von Lupusverlach: „_Persistance.Save() --> System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.“Das ist ein sehr dummer Fehler: Der Variable _Persistance ist scheinbar nie ein Persistance-Objekt zugewiesen worden. Mehr kannich nicht sagen - ich kenne ja deinen Code nicht. Zitat von Lupusverlach: „TableAdapter raus wirft?“Naja - im Dataset-Designer werden die Tabellen ja immer als DoppelPack dargestellt: Oben die Table, unten der TableAdapter. Da k…

Zitat von Lupusverlach: „da bekomme ich etwas Probleme mit dem Datenschutz“in post#11 sprichst du von einem Probe-Projekt. Und ein solches kannst du natürlich verzippen, wenn du Hilfe brauchst. Das ist übrigens eine sehr gute Idee, sich erstmal in einem Probe-Projekt die notwendigen Fertigkeiten anzueignen, bevor du dich an deine 100(!) Tabellen machst, und da womöglich einen Riesen-Schlamassel anrichtest. Wie gesagt: Das Herumfuchteln mit Commands und Reader, und Tabelle neuladen für jedes Inse…

Zitat von Lupusverlach: „Darfs auch WinRAR sein“Nein - Winrar habich nicht installiert. Wozu Winrar installieren, wenn zippen Windows-OnBord ist? Aber ich hab jetzt auch vergessen, warum du das Projekt uploadest. Erinnere ich das richtig, dass ich da nu einen DB-Zugriff mit der DbPersistance dranbasteln soll?

kommt aufs selbe raus. Den Fehler kann ich höchstwahrscheinlich ja nur dadurch beheben, dassich die Persistance richtig einbau. Aber wie gesagt: WinRar installiere ich nicht dafür - Zip ist für dich keine Option?

Zitat von Lupusverlach: „Parallelitätsverletzung: Der UpdateCommand hat sich auf 0 der erwarteten 1 Datensätze ausgewirkt“Ich bekomme diesen Fehler überhaupt nicht.

habs mal gebastelt. Allerdings das Mainform ganz neu gemacht. Du stehst aber noch ganz am Anfang, und musst scheints erst noch dieses erlernen: Visual Studio - Empfohlene Einstellungen Auch die DB scheint mir vermurkst - ich kann sie allerdings niht wirklich inspizieren (hab kein Access-Frontend installiert). Aber dass alle Tabellen mit 'tbl' anfangen ist Unfug und ein schlechtes Zeichen. Ein anderes schlechtes Zeichen ist die komplette Abwesenheit von DataRelations im Dataset. Wenn in der DB ta…

Zitat von Lupusverlach: „Ist denn eine DataRelations notwendig um das mit dem Dataset->Db zu verstehen?“Nein - es funzt nun ja (oder?). Das ist ja schoma die wichtigste Vorraussetzung, um sich Dataset->Db - Verständnis zu erarbeiten. Nee - bin ich heilfroh, dass die Db nicht so ist, wie sie dem Dataset nach aussieht. Beachte, dass zwischen Dataset->Db - Verständnis und dem Verständnis der AnwendungsEntwicklung mit typDataset ein himmelweiter Unterschied besteht. Und für eine sinnvolle Anwendungs…

Zitat von ErfinderDesRades: „habs mal gebastelt. Allerdings das Mainform ganz neu gemacht.“ Upsalla!! Mein Werk, in post#23 grossspurig angepriesen, ist ja garnet im Post(#23) angehängt. Ich verdächtige die Forum-Software, denn normal gelingt es mir eiglich, meine Werke anzuhängen. Wie dem auch sei. So sind natürlich alle posts nach #23 ziemlich sinnlos - also guck doch nochmal, ob das hier nu angehängte funzt. Darüber möchte ich im weiteren reden, und dieses habich auch gemeint, wenn ich sagte:…

Das ist mir ein Standard, den ich schon in Daten laden, speichern, verarbeiten - einfachste Variante vorstelle. Grund ist, dass bei komplizierten Bindings, zb mehrere DGVs, ComboColumns etc. beim Schliessen eine doofe Exception auftreten kann. Weil standardmässig werden beim Schliessen wohl zuerst die Components disposed, also die BindingSources. wenn aber einem Dgv der gebundenen ComboColumn die Bindingsource unterm Hintern weg-disposed wird, dann weint das DGV. Daher erzwinge ich mit dem Trick…

hat was mit dem Datensatz zu tun. Tritt bei mir nur bei ID=2 auf. Aber du kannst mal VB.NET-Quellcode (3 Zeilen) Derzeit kommt ein wahrhaft schauriges UpdateCommand zur Anwendung:SQL-Abfrage (1 Zeile) Mit .OverwriteChanges kommt ein einfaches:SQL-Abfrage (1 Zeile)Das stürzt nicht ab.

ja, in der frmMain.Designer.vb gibt es auch die Methode Dispose - aber anders implementiert. Dort muss sie gelöscht werden, weil dieselbe Methode zweimal geht natürlich nicht. Zitat von Lupusverlach: „Auch muss ich wohl irgendwas übersehene haben, denn die Speicherbefehle werden nicht ausgeführt“Versteh ich nicht. Nach dem abgebildeten Fehler kann das Projekt garnet kompilieren. Folglich kann auch kein Speicherbefehl ausgeführt werden. Ah - du hast mein Dispose auskommentiert. Langfristig wirst …

Der ist in deinem typisierten Dataset definiert. Zumindest war es in dem Projekt so, wo das noch funztete. Schau das bitte nach: Öffne das funktionierende Projekt, Rechtsklick auf KundenRow - zu Definition gehen. Scheinbar hast du in deim MySql-Projekt jetzt ein anderes typisiertes Dataset.

Versteh ich nicht. In meiner MySqlPersistance tritt der Fehler nicht auf. Hast du da iwie eine andere MySql-Dll eingebunden?

vielleicht lässt du die MySqlPersistance besser erstma da, wo sie gewesen ist? Also in ihrem eigenen Projekt? Funzt es dann? hmm - ich hab jetzt eben auch die MySqlPersistance nach MiniHelpers umgezogen. Und in MiniHelpers einen MySql-Verweis gesetzt - und zwar auf dieselbe dll, auf die auch inine MySqlPersistance der MySql-Verweis gesetzt ist. Wassollichsagn? - kompiliert.