Suchergebnisse

Suchergebnisse 1-9 von insgesamt 9.

  • Benutzer-Avatarbild

    @DerSmurf: Warum so umständlich? Warum machste das nicht so, wie in meinem Beispiel deiner Anwendung?: VB.NET-Quellcode (7 Zeilen) fertig

  • Benutzer-Avatarbild

    Dann änder' deine Prüfung ab - ist doch sicher einfacher als der 100-Zeilen-Code zum Kopieren des Datensatzes... da fällt dir sicher was besseres ein

  • Benutzer-Avatarbild

    ... und wenn du das im Edit-Dialog abfängst? Also z.B. beim Textbox-Leave von PurchasingPrice wird geprüft, ob der sich unterscheidet zum alten (den alten kannste ja vorher dir wegspeichern). Wenn ne Änderung ist, dann für OldPurchasingPrice den alten Wert eintragen und fertig. Also sowas hier: VB.NET-Quellcode (12 Zeilen) ich krieg' das mit dem Formatieren im Forum nicht hin, wenn das nicht aus VisualStudio stammt.. egal, man wird sehen was ich damit meine denke ich Beim Kopieren der Row verläs…

  • Benutzer-Avatarbild

    Zitat von DerSmurf: „wenn ich einen Artikel bearbeite“ bearbeitest du denn einen kopierten Artikel? Wenn ja, dann nimm die vorgeschlagene Property "IsCopied" oder wie auch immer man die nennen mag und frag die Property dann in deiner Prüfung ab.

  • Benutzer-Avatarbild

    Zitat von DerSmurf: „Aber wie soll ich die Property setzen, wenn ich meine frmEditArticle nicht vorher instanziere?“ VB.NET-Quellcode (9 Zeilen) fertig. Da brauchst keine Tuples usw. weil die Row ja schon da is. Und im Edit-DIalog fragst du eben bei deiner Prüfung ab, ob das ne Kopie ist oder nicht. EDIT: Im Übrigen: Zitat: „weil diese unique sein müssen“ wenn deine DataColumn auf Unique eingestellt ist, musste gucken ob das Kopieren dann noch so geht (das weiß Edr sicher besser), denn dann darf…

  • Benutzer-Avatarbild

    Zitat von ErfinderDesRades: „Neue Rows haben glaub .Detached“ ja, die haben .Detached. Auch würde ich den Vorschlag von @Kasi in jedem Fall umsetzen: Die Preisänderungen mit ArtikelID und Datum in eine separate Tabelle wegspeichern. Dann kannst du (ob du das jemals brauchst oder nicht), dir jederzeit ein View basteln, was dir z.B. eine Preisentwicklung anzeigen kann.

  • Benutzer-Avatarbild

    Zitat von DerSmurf: „Bei EditCurrent ist er Added.“ Ne, bei einer neuen Row ist der RowState Detached. Sobald die Anlage der Neuen (über newdialog oder per Code) abgeschlossen ist, sollte die Added sein. Wenn du eine bestehende editierst ist die Changed bzw. Modified Kannst dazu mal die Maus über die Properties halten wenn du .Rowstate eingibst, da wird das erklärt (oder im ObjectBrowser). Unchanged sind Rows, die nicht angepackt wurden.

  • Benutzer-Avatarbild

    Zitat von DerSmurf: „ist er bei mir Added.“ dann geh' doch auf Nummer sicher und prüfe nur, ob Detached oder nicht. Dann kann das ja wurscht sein wie die anderen RowStates mal sein könnten

  • Benutzer-Avatarbild

    Zitat von DerSmurf: „Ich prüfe auf added und der rest ist mir wurscht.“ Und genau aus folgendem Grund solltest du deine Prüfung auf Detached verlagern, sonst kann's dir passieren dass es mächtig Murks gibt. Wegen mir prüf' auf Not Detached, wenn das hilfreicher ist Zitat von ErfinderDesRades: „Bei EditCurrent kanns Added, Unchanged oder Modified sein. Je nachdem, ob der Datensatz frisch von Platte geladen wurde, durch vorherige Operationen verändert, oder überhaupt erst zugefügt wurde.“