Kompleter Artikel dupilzieren

  • VB.NET

Es gibt 16 Antworten in diesem Thema. Der letzte Beitrag () ist von GünterD.

    Kompleter Artikel dupilzieren

    Hall Zusammen,

    ich brauchte einen Tipp, wie ich möglichst elegant einen kompletten Artikel in einen neuen Datensatz kopieren kann.
    Zum "Artikel" gibt es eine DBS und dessen Eigenschaften 1:n-Beziehungen mit zugehörigen DBS.

    Ich möchte anschließend im "Duplizierten" Eigenschaften ändern um so dann eine Historie zu erhalten.

    Danke im Voraus
    Gruß Günter
    Gibt's nichts eleganteres, da den dbs doch die Verbindungen bekannt sein müssten.
    Hier ein Auszug aus meiner Datenstruktur und ein Beispiel für die 1:n Verbindungen, die überall gleich sind.
    Ich möchte aus "tbl_ArtikelStammdaten" eine bestimmte "ID" mit allen 1:n-Beziehungen duplizierem
    Bilder
    • Modell.jpg

      553,12 kB, 1.511×763, 21 mal angesehen
    • 1-n.jpg

      166,82 kB, 612×596, 18 mal angesehen
    Gruß Günter
    Was ist eine "Databindingsource"? Mir bekannt ist nur eine Klasse namens "Bindingsource" - meinst du die?

    Ansonsten kann man durchaus Methoden schreiben, die eine Datarow duplizieren.
    Allerdings werden die nie wirklich allgemeingültig, weil es das Datenmodell evtl. verbietet, Dubletten zu erzeugen in der Weise, wies die Methode grade tut.
    ZB kann auftreten, dass in bestimmten DAtenmodell-Konstellationen die neue Row gegen eine Unique-Constraint verstösst.
    Oder im Datenmodell ist für den PK kein Autowert eingestellt - dann kommt es zu ungültigen PK-Dubletten.

    Ansonsten hast du fast recht:

    GünterD schrieb:

    da den dbs doch die Verbindungen bekannt sein müssten.
    Die "Verbindungen" (es heisst "Relation", und es gibt auch eine Klasse die so heisst) sind nicht dem dbs (was immer das sein mag) bekannt, sondern sie sind im Dataset angelegt und dort auch abrufbar ("bekannt" also könnte man sagen).
    Das müsste man denn auch nutzen, wenn man eine allgemeine DataRow-Duplizier-Methode schreiben will.

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

    Sorry, ja dbs = bs = Bindingsource

    dann muss ich wohl in den sauren Apfel beißen und die Datensätze jeder verbundenen Tabelle mit der in der übergeordneten Tabelle erzeugten ID per "Insert Into" einfügen.
    Gruß Günter

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „GünterD“ ()

    Wenn eine echte DB hinter den Daten steckt und du die Datensätze eindimensional archivieren willst, würde ich mir eine View bauen, die die Datensätze so enthält, wie du sie benötigst und dann diese View (ggf. selektiv) in die Archivtabelle einfügen.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --
    So wie ich beschrieb.
    Erstelle eine View und eine entsprechende ArchivTabelle.
    Dann kopierst du die gewollten Daten der View in die ArchivTabelle.

    Oder du sparst dir den ersten Teil und kopierst direkt.

    SQL-Abfrage

    1. INSERT INTO Zieltabelle (Feld1, Feld2, Feld3) SELECT x.Feld1, x.Feld2, y.Feld3 FROM Tabelle1 x INNER JOIN Tabelle2 y ON x.ForeignKey=y.Id

    So wie es hier gemacht wird:
    stackoverflow.com/questions/44…-with-inner-join/44469617
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

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

    Naja, man könnte notfalls auch:

    VB.NET-Quellcode

    1. Dim NewRow = DataSet1.Tabelle.NewTabelleRow
    2. Dim CurrentRow = DoppelcastVomBindingSourceCurrent
    3. NewRow.ItemArray = CurrentRow.ItemArray
    4. For i = 0 To NewRow.ItemArray.Count - 1
    5. If DataSet1.Tabelle.Columns(i).Unique Then NewRow.Item(i) = DBNull.Value
    6. Next
    7. DataSet1.Tabelle.AddTabelleRow(NewRow)

    Aber das ist doch ziemlich notfalls.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.
    Wieso denn nun das?
    Ist doch Quatsch, einen Datenbank-Zugriff abzufahren, um mit Daten umzugehen, die du doch bereits beim Client hast. Und der Insert bringt dir ja auch nichts - dann ist auf der Datenbank ein neuer Datensatz - aber in deim Client noch nicht.
    Da musste ja noch weiter dran rumhexen.
    Und das für jede Tabelle extra neu coden.

    Statt das eben da abzuhandeln, wo die Daten verarbeitet werden - nämlich im Dataset.

    Aber vlt. bin ich ja auffm Holzweg - jetzt wird da ja iwo eine View erstellt - was immer damit gemeint sein mag.
    Also die Anforderung hat sich iwie geändert hin zu einem Konzept, was hier im Thread nicht klar benannt ist.
    Hallo EDR,

    habe leider erst gerade dein Kommentar #14 gelesen und … bin genau in das dort vor dir beschriebe Problem gelaufen.
    D.h. ich habe per SQL in den Tabellen die Kopien gespeichert und jetzt bekomme ich mein DGV nur aktualisiert, wenn ich das zugehörige FORM schließe und wieder öffne.

    Hättest du einen Tipp entweder
    1) wie bekomme ich die Aktualisierung des DGV ohne Schließen des FORMs hin oder
    2) wie kann ich statt kopieren in Tabelle dies in im Dataset erledigen?
    Gruß Günter
    naja - post#12 geht in die Richtung. Aber kann sein, es geht mit deim Datenmodell nicht.
    Jedenfalls sind Daten im Dataset zu bearbeiten, nicht in der Datenbank.
    Wenn du die Daten im Dataset bearbeitest brauchst du dich um DGV-Aktualisierung nicht zu kümmern - da kümmert sich ja Databinding drum.

    Ich empfehle übrigens immer, die Datenbank erstmal wegzulassen - hab ich das schon erwähnt?