DataGridView schmeißt NoNullAllowedException

  • VB.NET

Es gibt 15 Antworten in diesem Thema. Der letzte Beitrag () ist von Marsianer.

    DataGridView schmeißt NoNullAllowedException

    Hi,

    blöder Fehler in meinem DataGrindView. Das DGV funktioniert wunderbar, aber beim Anlegen neuer Datensätze bekomme ich eine NoNullAllowedException und zwar nicht(!) bei einem Autoincrement Primary Key (das Problem isja bekannt).

    Nee, ich habe Felder in der Tabelle, die hinter dem DGV steckt, die auf NullNotAllowed gesetzt sind und das soll auch so bleiben. Wenn ich jetzt mein DGV mit neuen Datensätzen befülle, kann folgendes passieren: Ich fülle eine Row mit einem neuen Datensatz und am Ende der Row drücke ich nochmal zB die Tabtaste. Dann springt der Cursor in eine neue Row und wennich dann zB die Form schließe oder auch nur speichern will - Bingo - Exception, weil die DGV schonmal - ohne dassich es wollte - ne neue Row angelegt hat. Ich kann den Fehler verhindern, indem ich 1x die Escapetaste drücke und so eine Art CancelEdit auslöse. Gleiches gilt, wennich vorm Speichern in eine andere (bestehende) Row des DGV wechsle. Aber das sind ja nu alles keine richtigen Lösungen und ich habe in Bing und sonstwo auchnichts richtiges als Lösung dazu gefunden. IWie mussich dazu aber was passendes basteln, weil schließlich soll das DGV auch vonnem undedarften User bedienbar sein.

    Anyone any idea?
    Danke!
    Ich code nur 'just for fun'! Damit kann ich jeden Mist entschuldigen, den mein Interpreter verdauen muss :D

    Hmmmm,

    ich fürchte das bringt mich nicht weiter. Das Problem ist eigentlich nicht ein fehlender Eintrag in der gewollten neuen Zeile (wenn der User da was verpennt, wird er weich validiert und kannet aus der Zeile raus :D ). Das Problem ist, dass mir das DGV ungewollt ne neue Zeile anlegt, wennich voner letzten Zelle meines neuen Datensatzes mit der Tab-Taste weiterspringe. Und diese neue Zeile ist dann leer, die sollte ja eigentlich garnet da sein. Wenn ich jetzt Default-Values eintrage, dann habbich hinterher womöglich Datensätze im DGV, die es gar nicht geben sollte.

    Vielleicht wäre es besser das DGV so einzustellen, dass es keine neuen Datensätze zulässt und neue Zeilen dann übern neuen Button einzufügen?
    Ich code nur 'just for fun'! Damit kann ich jeden Mist entschuldigen, den mein Interpreter verdauen muss :D

    natürlich ist das möglich, aber als Schwabe spart man auch an Steuerelementen ;)

    Bei mir entsteht auch son automatischer Datensatz, wenn man die Hinzufügezeile betritt, jedoch wenn man sie wieder verläßt, ohne etwas eingegeben zu haben, verschwindet der wieder.
    vermutlich gibst du programmgesteuert iwas ein, und dann denkt die BindingSource, das sei ernst gemeint.

    Du hast recht. Wenn eine neue Zeile entsteht, fügt das Prog ohne mein Zutun einen neuen PrimaryKey ein (is Autoincrement). Aber das willich natürlich auch vom Grundsatz her, wenn ein neuer Datensatz angelegt wird.

    Aber andererseits... dass die sogenannte Order-Nummer (d.h. der PK) angezeigt wird, is eigentlich nur reine Kosmetik.

    Weistduwas? Ich kill mal die Column und guck mal was passiert. 8-)

    EDIT: Bringt leider nix, er schmeißt die Exception immer noch :thumbdown:
    Ich code nur 'just for fun'! Damit kann ich jeden Mist entschuldigen, den mein Interpreter verdauen muss :D

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

    hmm. bei mir gilt AutoIncrement nicht als Eingabe, die BindingSource.EndEdit verursacht.
    Also bei mir erzeugt er einen Datensatz, inklusive generiertem PrimKey, und wenn der User nix reinmacht, verschwindet der auch wieder.

    Kannst du eine TestApp machen, die den Fehler reproduziert?

    ErfinderDesRades schrieb:

    ist angekommen, aber ich kann dir nicht antworten per mail.
    hat das eine bedeutung?

    ... Versteh ich nicht ?( Ist dochn ganz normaler googlemail-account.

    Ansonsten, die Variante mit "Stop": Kannte ich noch garnet :) Mussich mir zu Hause heute gleich mal ansehen. Danke!
    Ich code nur 'just for fun'! Damit kann ich jeden Mist entschuldigen, den mein Interpreter verdauen muss :D

    ... ich find die Macke nicht. Da ich Preuße bin, habe ich mir jetzt zwei Buttons (Neu und Löschen) eingebaut und dafür dem DGV die entsprechenden Optionen gestrichen. Somit habe ich programmtechnisch über die BindingSource die Kontrolle, wann da was eingefügt oder rausgenommen wird. Das funktioniert erstmal. Falls mir (oder jemand anderem) noch ne Erleuchtung kommt, kann ich das problemlos umstellen (Buttons raus und die die Optionen zum Einfügen/Löschen im DGV wieder aktivieren). 8-)
    Ich code nur 'just for fun'! Damit kann ich jeden Mist entschuldigen, den mein Interpreter verdauen muss :D

    Sorry, mein Fehler,

    iwie habbich dein Codeschnipsel missverstanden. Ich dachte, es wäre ne Art Nebenbemerkung/Nebenverbesserung. Ich habe unterschätzt, dass so ne kleine Änderung die Lösung ist. Sorry, sorry, sorry.
    Hinzu kommt, dass ich nicht kapiere, wieso es jetzt funktioniert. Ich steh echt davor, wie der Ochs vorm Tor. Warum sorgt das Return dafür, dass die Exception abgefangen wird? Ich weiß, ich müsste selbst drauf kommen, aber... 'n ganz little Hinweis? Bitte?

    Und nochma danke! :thumbsup:
    Ich code nur 'just for fun'! Damit kann ich jeden Mist entschuldigen, den mein Interpreter verdauen muss :D

    na, die Methode heißt doch BuchungErfolgreichValidiert As Boolean

    VB.NET-Quellcode

    1. Private Function BuchungErfolgreichValidiert() As Boolean
    2. If Not Me.ValidateChildren() Then
    3. Stop
    4. Return False
    5. End If
    Und dann sollsedoch False zurückgeben, wenn die Validierung fehlschlägt.
    Und du hattest den Rückgabewert von Me.ValidateChildren() ignoriert, dabei, wenn die False zurückgibt, ist die Validierung bereits fehlgeschlagen, und deine eigene Validierung darf dann garnimmer zum Zuge kommen.

Facebook
Telefonspende