Datengebundene Textbox als Eingabefeld

  • VB.NET

Es gibt 40 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    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, 115 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

    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.

    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

    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.

    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, 113 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

    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

    • Projektmappe00.zip

      (609,4 kB, 116 mal heruntergeladen, zuletzt: )

    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

    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.

    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

    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“ ()

    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, 118 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“ ()

    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“ ()

    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

    ErfinderDesRades schrieb:

    Darüber möchte ich im weiteren reden, und dieses habich auch gemeint, wenn ich sagte: "es funzt nun, oder?"


    Also mit Access funktioniert es prima. beim umstellen auf MySQL gibt es jedoch Probleme :(
    In dem Abschnitte fragt er an "Der Typ "KundenRow" ist nicht definiert.

    Wo wird denn der und wie definiert?

    VB.NET-Quellcode

    1. Private Sub Button_Click(sender As Object, e As EventArgs) Handles BtnEnde.Click, BtnSpeichern.Click, BtnNeu.Click, BtnLoeschen.Click
    2. Select Case True
    3. Case sender Is BtnSpeichern : BSKunden.EndEdit() : _Persistance.Save()' hier sollten alle befüllten Bindingsources EndEdit machen
    4. Case sender Is BtnNeu : BSKunden.AddNew()
    5. Case sender Is BtnLoeschen : DirectCast(DirectCast(BSKunden.Current, DataRowView).Row, KundenRow).Delete()
    6. Case sender Is BtnEnde : Application.Exit()
    7. End Select
    8. End Sub
    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

    ErfinderDesRades schrieb:

    Zumindest war es in dem Projekt so, wo das noch funztete.

    funktioniert ja auch immer noch. Der Fehler war eindeutig vor dem Monitor.
    Nach dem ich ein Imports Projektverwaltung.datenpvDataSet gesetzt hatte war der Fehler weg.
    Und sogar 2 Minuten bevor ich deine Antwort gelesen hatte, ab und zu komme ich sogar von selbst drauf :D
    Aus irgend einem Grund hatte ich das gelöscht, keine Ahnung warum. Kalte Finger? Zu wenig Kaffee? Ich weiß es nicht mehr.

    Dafür nun das:
    MysqlPersistance..vb(27,34): error BC30512: "Option Strict On" lässt keine impliziten Konvertierungen von "Object" in "MySqlCommand" zu.

    Muss dazu sagen, die MysqlPersistance.vb habe ich in der MiniHelpers untergebracht.
    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

    ErfinderDesRades schrieb:

    Versteh ich nicht.

    Und ich erst :/

    ErfinderDesRades schrieb:

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

    Eingebunden in beiden Projekte (also miniHelpers und der Anwendung): packages\MySql.Data.6.9.12\lib\net45\MySql.Data.dll
    Nach dem Starten folgende Fehlermeldung:


    Jedoch Eingebunden im beiden Projekte (also miniHelpers und der Anwendung): C:\Program Files (x86)\MySQL\MySQL Installer for Windows\MySql.Data.dll
    Dann eben "Option Strict On" lässt keine impliziten Konvertierungen von "Object" in "MySqlCommand" zu.

    P.S wie gesagt, die Muss dazu sagen, die MysqlPersistance.vb habe ich in der MiniHelpers untergebracht.
    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