Datengebundene Textbox als Eingabefeld

  • VB.NET

Es gibt 34 Antworten in diesem Thema. Der letzte Beitrag () ist von Lupusverlach.

    Neu

    ErfinderDesRades schrieb:

    Den Fehler kann ich höchstwahrscheinlich ja nur dadurch beheben, dassich die Persistance richtig einbau.


    Wow, vielen dank wenn Du das wirklich machen würdest.

    ErfinderDesRades schrieb:

    Aber wie gesagt: WinRar installiere ich nicht dafür - Zip ist für dich keine Option?


    doch doch, Winrar kann auch ZIP Dateien erstellen.
    Dateien
    • Projektmappe.zip

      (1,45 MB, 3 mal heruntergeladen, zuletzt: )
    Mit freundlichen Dinges

    Lupus
    P-S: bei allen meine Fragen beziehen sich auf das arbeiten mit Visual Studio 2019 auf Win 10/64 bit und MySQL

    Neu

    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 tatsächlich dementsprechend überhaupt keine Relationen (alias 'Beziehungen') eingerichtet sind, kann man das kaum als 'relationale Datenbank' bezeichnen - dann ists ja nur ein Haufen Tabellen.

    Von daher solltest du dieses hier sorgfältigst(!) durcharbeiten und beherzigen: codeproject.com/Articles/10309…l-Datamodel-for-Beginners
    Und auch die Folge-Artikel.

    Das Datenmodell ist die Basis einer Anwendung.
    Es existiert zunächstmal im Kopf. Dann in der Datenbank. Dann im typDataset.
    Bei einer DatasetOnly-Anwendung spart man sich viel viel Aufwand (zB diesen ganzen Thread) - weil man sich die Datenbank spart.

    Es ist unmöglich auf einem kranken Datenmodell eine gesunde Anwendung aufzubauen.

    Neu

    ErfinderDesRades schrieb:

    Auch die DB scheint mir vermurkst - ich kann sie allerdings niht wirklich inspizieren (hab kein Access-Frontend installiert).

    Du Urteilst etwas zu früh

    ErfinderDesRades schrieb:

    Aber dass alle Tabellen mit 'tbl' anfangen ist Unfug und ein schlechtes Zeichen.

    Das ist bei Access Entwicklung Standard. Siehe z.B. hier access-tutorial.de/namenskonventionen.htm Da die Datenbank ja incl. Daten schon über 20 Jahre besteht (logischerweise immer mal wieder angepasst), sah ich jetzt keinen Grund das zu ändern.

    ErfinderDesRades schrieb:

    Ein anderes schlechtes Zeichen ist die komplette Abwesenheit von DataRelations im Dataset. Wenn in der DB tatsächlich dementsprechend überhaupt keine Relationen (alias 'Beziehungen') eingerichtet sind, kann man das kaum als 'relationale Datenbank' bezeichnen - dann ists ja nur ein Haufen Tabellen.

    Es ist ja nur ein klitzekleines Probeprojekt um das zu verstehen was mir von dir Empfohlen wurde. Daher ist ja auch nur eine Tabelle davon von Bedeutung. In der Access Anwendung gibt es jede Menge DataRelations
    Ist denn eine DataRelations notwendig um das mit dem Dataset->Db zu verstehen? Wäre nun auch kein Hexenwerk das noch rein zu packen.

    ErfinderDesRades schrieb:

    Das Datenmodell ist die Basis einer Anwendung.
    Es existiert zunächstmal im Kopf. Dann in der Datenbank. Dann im typDataset.

    In dem Fall baue ich eine sehr gut laufende Access Anwendung um in eine VB.NET Anwendung, von daher sind alle Tabellen und Beziehungen schon vorhanden.
    Der Umbau wird nur deshalb gemacht, weil Access nicht mit Datenbanken arbeiten kann, die nicht im Intranet liegen. Nur über ODBC Driver, jedoch ist das viel zu langsam.
    Mit freundlichen Dinges

    Lupus
    P-S: bei allen meine Fragen beziehen sich auf das arbeiten mit Visual Studio 2019 auf Win 10/64 bit und MySQL

    Neu

    Lupusverlach schrieb:

    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 AnwendungsEntwicklung sind DataRelations unabdingbar.
    Eine banale Anforderung wäre, einen Kunden anzuzeigen, seine Bestellungen inklusive aller darin bestellten Artikel.
    Wie gesagt: banal - wenn DataRelations da sind.
    Aber annähernd unmöglich, wenn nicht.



    So, ich hab jetzt die Namenskonventionen überflogen.
    Ja, für ein Access-Frontend mag das gelten.
    In einer .Net-Anwendung werden von der Acces-Datenbank aber nur die Tabellen benutzt.
    Keine Access-BuildIn-Queries, Access-BuildIn-Berichte, Access-BuildIn-Formulare, Access-BuildIn-Module, Access-BuildIn-Klassenmodule.
    Von allen diesen Dingen bleiben nur die Tabellen übrig, und somit gibt es nichts unterschiedliches mehr, was durch ungarische Notation unterschieden würde.
    Und in einer typisierten Sprache wie vb.net ergibt es auch keinen Sinn, datentypen durch Prefixe kenntlich zu machen.
    Das ist nur unleserlich - die Typ-Sicherheit wird durch andere, viel wirksamere Mechanismen gewährleistet.

    Wie gesagt: studiere sorgfältig das gegebene Tutorial.

    Neu

    ErfinderDesRades schrieb:

    Nein - es funzt nun ja (oder?).

    Nicht wirklich.Habe es hier noch mal angehängt. Die Tabellen fangen jedoch immer noch mit "tbl" an, später in der richtigen Anwendung werde ich dann disziplinierter :)
    1. Änderung in einem Datensatz, bzw. einer Textbox mit Return bestätigen
    2. auf den Button "DS speichern" klicken
    3. Nächten Datensatz auswählen
    4. Änderung in einer Textbox mit Return bestätigen
    5. auf den Button "DS speichern" klicken
    6. Dann kommt die Fehlermeldung.
    Interesant finde ich es, wenn ich genau diese Mappe auf MySQL umstelle, dann geht es.
    Gibt es da doch irgendwelche Unterschiede in der Datenverarbeitung?

    ErfinderDesRades schrieb:

    Und für eine sinnvolle AnwendungsEntwicklung sind DataRelations unabdingbar.
    Eine banale Anforderung wäre, einen Kunden anzuzeigen, seine Bestellungen inklusive aller darin bestellten Artikel.
    Wie gesagt: banal - wenn DataRelations da sind.
    Aber annähernd unmöglich, wenn nicht.


    da sind wir uns sowas von einig

    ErfinderDesRades schrieb:

    So, ich hab jetzt die Namenskonventionen überflogen.
    Ja, für ein Access-Frontend mag das gelten.


    ich werde mit Sicherheit noch einige Altlasten aus MS Access mitbringen :D
    Dateien
    • Projektmappe.zip

      (308,63 kB, 1 mal heruntergeladen, zuletzt: )
    Mit freundlichen Dinges

    Lupus
    P-S: bei allen meine Fragen beziehen sich auf das arbeiten mit Visual Studio 2019 auf Win 10/64 bit und MySQL

    Neu

    ErfinderDesRades schrieb:

    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: "es funzt nun, oder?"
    Dateien

    Neu

    ErfinderDesRades schrieb:

    Wie dem auch sei.

    Hallo EDR - das hatte ich noch nie?
    Werden die Controls der Form beim Schließen nicht sowieso zerstört?
    Welche Objekte zum disposen sind, ist mir jetzt nicht ganz klar...

    VB.NET-Quellcode

    1. 'Form overrides dispose to clean up the component list.
    2. Protected Overrides Sub Dispose(ByVal disposing As Boolean)
    3. Try
    4. If disposing AndAlso components IsNot Nothing Then
    5. Me.SuspendLayout()
    6. While Me.Controls.Count > 0 : Me.Controls(0).Dispose() : End While
    7. components.Dispose()
    8. End If
    9. Finally
    10. MyBase.Dispose(disposing)
    11. End Try
    12. End Sub

    Neu

    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, dass erst die Controls verschwinden.

    Neu

    ErfinderDesRades schrieb:

    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.

    Das macht uns so menschlich ;)

    und nun passiert es wie folgt:
    1. Änderung in einem Datensatz
    2. drücke auf "save"
    3. Nächten Datensatz auswählen
    4. Änderung in einer Textbox
    5. drücke auf "save"
    Dann kommt die Fehlermeldung im Anhang.


    Damit bin ich genau an der Stelle, an der ich schon einmal war ;(
    Mit freundlichen Dinges

    Lupus
    P-S: bei allen meine Fragen beziehen sich auf das arbeiten mit Visual Studio 2019 auf Win 10/64 bit und MySQL

    Neu

    hat was mit dem Datensatz zu tun.
    Tritt bei mir nur bei ID=2 auf.

    Aber du kannst mal

    VB.NET-Quellcode

    1. builder = New OleDbCommandBuilder(adp) With {.QuotePrefix = "`", .QuoteSuffix = "`"}
    2. ändern zu:
    3. builder = New OleDbCommandBuilder(adp) With {.QuotePrefix = "`", .QuoteSuffix = "`",.ConflictOption=ConflictOption.OverwriteChanges}


    Derzeit kommt ein wahrhaft schauriges UpdateCommand zur Anwendung:

    SQL-Abfrage

    1. UPDATE `tblKunden` SET `KdNr` = ?, `Name1` = ?, `Name2` = ?, `Straße` = ?, `PLZ` = ?, `Ort` = ?, `BL` = ?, `NeuAnlage` = ?, `User` = ?, `EMail` = ?, `url` = ?, `Vertreter` = ? WHERE ((`ID` = ?) AND ((? = 1 AND `KdNr` IS NULL) OR (`KdNr` = ?)) AND ((? = 1 AND `Name1` IS NULL) OR (`Name1` = ?)) AND ((? = 1 AND `Name2` IS NULL) OR (`Name2` = ?)) AND ((? = 1 AND `Straße` IS NULL) OR (`Straße` = ?)) AND ((? = 1 AND `PLZ` IS NULL) OR (`PLZ` = ?)) AND ((? = 1 AND `Ort` IS NULL) OR (`Ort` = ?)) AND ((? = 1 AND `BL` IS NULL) OR (`BL` = ?)) AND ((? = 1 AND `NeuAnlage` IS NULL) OR (`NeuAnlage` = ?)) AND ((? = 1 AND `User` IS NULL) OR (`User` = ?)) AND ((? = 1 AND `EMail` IS NULL) OR (`EMail` = ?)) AND ((? = 1 AND `url` IS NULL) OR (`url` = ?)) AND ((? = 1 AND `Vertreter` IS NULL) OR (`Vertreter` = ?)))


    Mit .OverwriteChanges kommt ein einfaches:

    SQL-Abfrage

    1. UPDATE `tblKunden` SET `KdNr` = ?, `Name1` = ?, `Name2` = ?, `Straße` = ?, `PLZ` = ?, `Ort` = ?, `BL` = ?, `NeuAnlage` = ?, `User` = ?, `EMail` = ?, `url` = ?, `Vertreter` = ? WHERE ((`ID` = ?))
    Das stürzt nicht ab.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Neu

    ErfinderDesRades schrieb:

    hat was mit dem Datensatz zu tun.
    Tritt bei mir nur bei ID=2 auf.

    Keine Ahnung, habe es noch mal gemacht. tatsächlich, immer nur der Datensatz mit der ID 2.
    Den Datensatz hatte ich dann dupliziert und Datensatz mit ID 2 gelöscht. Der neue Datensatz hat nun die ID 34. Nun tritt der Fehler dort auf.
    Mit der Änderung .ConflictOption=ConflictOption.OverwriteChanges} jedoch läuft es.

    Dafür habe ich nun in einem anderen Projekt eine Fehlermeldung.
    Hatte es vollständig neu aufgebaut (weil die Namen und so falsch waren) und dort erhalte ich:


    Auch muss ich wohl irgendwas übersehene haben, denn die Speicherbefehle werden nicht ausgeführt ?(
    Dateien
    • Mustermappe.zip

      (342,4 kB, 2 mal heruntergeladen, zuletzt: )
    Mit freundlichen Dinges

    Lupus
    P-S: bei allen meine Fragen beziehen sich auf das arbeiten mit Visual Studio 2019 auf Win 10/64 bit und MySQL

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Lupusverlach“ ()

    Neu

    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.



    Lupusverlach schrieb:

    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 du es aber brauchen, siehe Erklärungen in post#28,#29

    Ansonsten funzt das Speichern doch fabelhaft. Du hast doch Access - guck in die Datenbank, und zwar die in \bin\debug\.

    Aber kannst du nicht wissen - Grund der Irritation ist diese komische MS-Voreinstellung: FAQ: Db speichern failt

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Neu

    ErfinderDesRades schrieb:

    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.

    Das dachte ich mir, sag ja auch schon die Fehlermeldung. Dachte weil es bei bei deiner Antwort in der Projektmappe00 Mappe in post#27 auch zweimal ist, also dachte ich..... Hatte das Augenmerkmal jedoch nicht darauf das es dort in einem anderen Formular ist ;)

    ErfinderDesRades schrieb:

    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 du es aber brauchen, siehe Erklärungen in post#28,#29

    Richtig, ich hatte es auskommentiert um zu sehen was es sonst noch Fehlermeldungen bringt. Das es benötigt wird habe ich verstanden.

    ErfinderDesRades schrieb:

    Ansonsten funzt das Speichern doch fabelhaft. Du hast doch Access - guck in die Datenbank, und zwar die in \bin\debug\. Aber kannst du nicht wissen - Grund der Irritation ist diese komische MS-Voreinstellung: FAQ: Db speichern failt

    Deswegen hatte es mit MySQL funktioniert, als ich vor ein paar Wochen es schon mal versucht hatte. Dann lag der Fehler nur daran, ich war schon kurz davor de Tischkante zu verspeisen.

    Kurz: Läuft. dann experimentiere ich mal weiter.
    Mit freundlichen Dinges

    Lupus
    P-S: bei allen meine Fragen beziehen sich auf das arbeiten mit Visual Studio 2019 auf Win 10/64 bit und MySQL