Announcement

Collapse
No announcement yet.

Datenbank und OnChange-Event eines Datensatz

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Datenbank und OnChange-Event eines Datensatz

    Hallo,

    ich versuche mich in die Anwendungsentwicklung mit C# einzuarbeiten. Hier das Arbeiten mit Datenbanken.

    Ich habe eine Anwendung erstellt die erfolgreich Daten in einem DataGridView anzeigt. Daten können erstellt und gespeichert werden.
    Ich arbeite mit einer Access-DB, TableAdapter und BindingSource.

    Meine Frage: Gibt es irgendwo ein Event, welches ausgelöst wird, wenn in einem Datensatz die Änderung durchgeführt wird?

    Das Event ListChanged feuert erst nachdem der Datensatz geändert und verlassen wird. Ich brauche das event aber früher - sobald das Editieren beginnt.

  • #2
    Das das Editieren beginnt weiß nur das DataGridView. Insofern mußt du ein Event des Grids fangen zum Beispiel DataGridView.CellBeginEdit .

    PS. Falls du aus der Delphi Welt kommst (Das hier ist ein eganze typische Frage) vergiß das überflüssige New, Edit, Post Spiel von TQuery Komponenten. Das war dort nötig weil man dabei je nach Komponente direkt in der DB hantierte. Eine Datatable ist aber eine komplette Offline In Memory Datenmenge da ist die Unterscheidung hinfällig ob man denn die Daten nur anguckt oder editiert.

    Comment


    • #3
      Danke

      Ja genau.. ich komme aus der Delphi-Welt.

      Ich versuche gerade zu entscheiden, ob ich von Delphi nach C# wechseln soll und stelle einige Anwendungsfälle nach.
      Noch kommen mir die C# Datenbank-Kompos sehr umständlich vor. Das liegt sicher daran, dass nirgens das Konzept und das Zusammenspiel der Kompos beschrieben wird. (Oder hat jemand eine Doku die sich mit der Datenbankanbindung befasst?)

      Danke für die Antwort. Ich hatte nur gehofft, eine zentrale Stelle (wie z.B die TDataSource) zu finden, die solche Events und Zustände verwaltet.

      Comment


      • #4
        Danke für die Antwort. Ich hatte nur gehofft, eine zentrale Stelle (wie z.B die TDataSource) zu finden, die solche Events und Zustände verwaltet.
        Eine Datatable hat solche zentralen Events nur die Trennung zwischen UI und Daten ist in .Net deutlicher ausgeprägt. Und editieren ist nun mal eine reine UI Geschichte. Ich wüßte auch nicht wofür man das 'ich werde gerade editiert' Wissen braucht?

        Comment


        • #5
          Ich habe dieses Event immer genutzt um z.B ein 'Speichern'-Button zu enablen.
          Sobald Editiert wird, werden die Tasten 'Cancel' und 'Save' enabled.

          Bei einem Grid mag das alles funktionieren.

          Wenn aber nur einzelne Textboxes auf einem Formular angezeigt werden, kann ich nach dem editieren nicht den Datensatz wechseln.
          Wie würde ich herausfinden ob der Datensatz verändert wurde?

          Comment


          • #6
            Wenn aber nur einzelne Textboxes auf einem Formular angezeigt werden, kann ich nach dem editieren nicht den Datensatz wechseln.
            Nach dem Editieren heißt wenn du den Focus von der Textbox genommen hasst.

            Wie würde ich herausfinden ob der Datensatz verändert wurde?
            Der RowChanged Event der Datatable würde dann gefeuert.
            Wenn die Aufgabe UI nah ist die du in diesem Event ausführen willst würde ich aber bei BindingSource.ListChanged bleiben der auch gefeuert wird.

            Comment


            • #7
              Ok... Danke für Deine Antworten.
              Ich sehe, das der Umstieg auf C# nicht am Wochenende funktioniert :-)
              Die ganze Datenbank-Bindung ist um einiges aufwändiger als in Delphi. Auch das Anpassen der Kompos an die Kundenwünsche ist um einiges umständlicher.
              Als Entwickler, der morgen eine Lösung für ein Problem von heute liefern muß, kann ich NOCH nicht ganz einsehen warum ich zu C# wechseln sollte.

              Ich bleibe hart und bleib am Ball (.. und lese Bücher...) :-)

              Comment


              • #8
                Die ganze Datenbank-Bindung ist um einiges aufwändiger als in Delphi. Auch das Anpassen der Kompos an die Kundenwünsche ist um einiges umständlicher.
                Als Entwickler, der morgen eine Lösung für ein Problem von heute liefern muß, kann ich NOCH nicht ganz einsehen warum ich zu C# wechseln sollte.
                Ohne umlernen geht es nicht. Wenn es schnell gehen muss ist man natürlich immer besser bedient mit dem was man schon beherrscht als wenn man noch eine Portion lernen drauf packen muss. Du solltest also vorsichtiger sein mit den Worten 'aufwändiger' oder 'umständlicher'. Es ist vor allen Dingen anders. Die Beurteilung ob das 'aufwändiger' oder 'umständlicher' solltest du treffen wenn ein Teil der Lernkurve bereits hinter dir liegt und du nicht mehr versuchst in der zu erlernenden Sprache so zu programmieren wie in Delphi. 'Wie in Delphi' wird immer am besten in Delphi funktionieren. Von jemanden der den Umstieg (und ein par andere ) schon mal hinter sich gebracht hat kann ich dir sagen das der Blick zurück auf Delphi eher so aussieht das ich mich frage wie ich die Delphi Methode jemals gut finden konnte Das liegt dann aber wahrscheinlich auch weniger an der Qualität von Delphi sondern eben das man sich eine andere Programmiermethodik aneignet die eben nicht mehr 'wie in Delphi' lautet und man dort mit dem konkreten Problem hier gar nicht konfrontiert ist.

                Comment

                Working...
                X