Mit Linq SubmitChanges ohne TimeStamp und StoredProcedures zur gleichen Zeit

Question

Ich verwende Sql-Tabellen ohne Rowversion oder Zeitstempel. Allerdings muss ich Linq verwenden, um bestimmte Werte in der Tabelle zu aktualisieren. Da Linq nicht wissen können, was zu aktualisieren Werte I ein zweites Datacontext bin mit dem aktuellen Objekt aus Datenbank abgerufen werden und sowohl die Datenbank und das eigentliche Objekt als Input für das Verfahren wie so anbringen verwenden:

Public Sub SaveCustomer(ByVal cust As Customer) 
    Using dc As New AppDataContext() 
     If (cust.Id > 0) Then 
      Dim tempCust As Customer = Nothing 

      Using dc2 As New AppDataContext() 
       tempCust = dc2.Customers.Single(Function(c) c.Id = cust.Id) 
      End Using 

      dc.Customers.Attach(cust, tempCust) 
     Else 
      dc.Customers.InsertOnSubmit(cust) 
     End If 

     dc.SubmitChanges() 
    End Using 
End Sub 

Während dies tut Ich habe jedoch ein Problem: Ich verwende auch StoredProcedures, um bestimmte Felder des Kunden zu bestimmten Zeiten zu aktualisieren. Nun stellen Sie den folgenden Workflow:

1. Get Kunden aus der Datenbank
2. ein Kundenfeld auf einen neuen Wert setzen
3. Verwenden Sie eine gespeicherte Prozedur
4. Anruf SaveCustomer einen anderen Kunden Feld

zu aktualisieren Was jetzt passiert, ist, dass die SaveCustomer-Methode das aktuelle Objekt aus der Datenbank abruft, das den im Code gesetzten Wert nicht enthält, aber den von der gespeicherten Prozedur gesetzten Wert enthält. Wenn Sie dies mit dem tatsächlichen Objekt verbinden und dann abschicken, aktualisiert es den in Code gesetzten Wert ebenfalls in der Datenbank und ... tadaaaa ... setzt den anderen auf NULL, da das tatsächliche Objekt nicht das von der Änderung vorgenommene enthält gespeicherte Prozedur.

War das verständlich?

Gibt es Best Practices zur Lösung dieses Problems?

Answer 1

Wenn Sie Änderungen hinter der Rückseite des ORM vornehmen und keine Parallelitätsprüfung verwenden, werden Sie Probleme haben. Sie zeigen nicht, was Sie in Schritt "3" getan haben, aber IMO sollten Sie das Objektmodell aktualisieren, um diese Änderungen widerzuspiegeln, möglicherweise unter Verwendung von OUTPUT TSQL-Parametern. Oder; bleiben Sie objektorientiert.

Natürlich etwas ohne Gleichzeitigkeitsprüfung tun, ist ein guter Weg, Daten zu verlieren - so meine bevorzugt Option ist einfach „ein rowversion hinzufügen“. Sonst könnten Sie vielleicht das aktualisierte Objekt auslesen und Dinge zusammenführen ... irgendwie erraten, was die richtigen Daten sind ...

Answer 2

Wenn Sie Ihr Objekt von einem Kontext trennen und einen anderen für das Update verwenden, Sie müssen entweder das ursprüngliche Objekt beibehalten, eine Zeilenversion verwenden oder eine Hashing-Routine in Ihrer Datenbank implementieren und den Hash als Teil Ihres Objekts beibehalten. Von diesen empfehle ich auch die Option Rowversion. Wenn Sie den aktuellen Wert als ursprünglichen Wert verwenden, wie Sie es gerade versuchen, wird nur nach Nebenläufigkeitsproblemen gefragt.