Announcement

**Andreas Kosch** · 16.08.2004, 05:56

Hallo,

welche WHERE-Einschr�nkung nutzt die vom DataAdapter implizit beim Zur�ckschreiben in die Datenbank verwendete UPDATE-Anweisung (siehe DataAdapter-Eigenschaft UpdateCommand)? Immer dann, wenn beim UPDATE-Aufruf in der Datenbanktabelle kein Datensatz zur WHERE-Einschr�nkung passt, l�st ADO.NET die Exception DBConcurrencyException aus. Als Gr�nde kommen nur 2 F�lle in Frage: 
1. Der zu aktualisierende Datensatz wurde in der Zwischenzeit von einem anderen Benutzer gel�scht, oder 
2. Zur WHERE-Einschr�nkung der UPDATE-Anweisung gibt es kein Gegenst�ck in der Tabelle.

Wenn die UPDATE-Anweisung als WHERE-Einschr�nkung zus�tzlich zum Prim�rschl�sselwert auch die alten Feldwerte aller Spalten der Tabelle vergleicht (optimistisches Sperrverfahren), muss das nach dem UPDATE �ber SELECT neu eingelesene DataSet zur�ck zum Client, damit dort f�r den 2. Update-Aufruf die "richtigen" Feldwerte als WHERE-Einschr�nkung genutzt werden k�nnen.
&#10

**Klaus L�denscheidt** · 16.08.2004, 07:47

Hallo,

die WHERE-Klausel enth�lt alle Feldnamen als Parameter. Ich lese die Daten nach dem Update jedoch nicht neu ein. Auf der Clientseite rufe ich lediglich AcceptChanges() auf dem DataSet auf.

Ich habe die Serverseite mittlerweile detailliert debugged. Das �bergebene DataSet enth�lt die korrekten Originalwerte, welche f�r das Update-Statement ben�tigt werden. Was mich wundert ist der Aufbau der Where-Bedingung. Sie sieht in etwa so aus:

... where ( (<Mein_PrimaryKey> = @p10) AND ((@p11 = 1 AND MANDANT IS NULL) OR (MANDANT = @p12)) AND ...

Ich frage mich, was "@p11 = 1" bedeutet. Dieses Konstrukt gilt f�r alle Felder der Tabelle.

Gibt es eine M�glichkeit herauszufinden, welche Werte die Parameter beim Update haben

**Andreas Kosch** · 16.08.2004, 09:38

Hallo,

>..welche Werte die Parameter beim Update haben ?

im Fall des MS SQL Server w�rde ich hier den Profiler auf die Lauer legen, damit dieser alle beim SQL Server eintreffenen Aufrufe mitprotokolliert.

>Dieses Konstrukt gilt f�r alle Felder der Tabelle.

Immer dann, wenn eine Spalte einer Tabelle den NULL-Zustand zul�sst, muss bei der WHERE-Einschr�nkung dieser Zustand explizit �ber IS NULL gepr�ft werden. Normalerweise sieht das dann aber so aus:

a) Beispieltabelle
<pre>
CREATE TABLE UpdDemo
(
recid INTEGER NOT NULL IDENTITY PRIMARY KEY,
wert1 INTEGER NOT NULL,
wert2 INTEGER NULL
)
GO
</pre>
b) Die vom SqlDataAdapter generierte Anweisung:
<pre>
UPDATE UpdDemo SET
wert1 = @wert1, wert2 = @wert2
WHERE
(recid = @Original_recid) AND
(wert1 = @Original_wert1) AND
(wert2 = @Original_wert2 OR @Original_wert2 IS NULL AND wert2 IS NULL);
 
SELECT recid, wert1, wert2
FROM UpdDemo
WHERE (recid = @recid)
</pre>
Der SqlDataAdapter liest den Datensatz in der BATCH-Anweisung neu ein, damit auch die von eventuell wirksamen Triggern vorgenommenen �nderungen garantiert beim Client landen

**Klaus L�denscheidt** · 16.08.2004, 10:45

Mittlerweile habe ich herausgefunden, wo mein Problem liegt. Dein Hinweis mit den Originalwerten hat mich letztendlich auf die richtige Spur gebracht. Alle Tabellen in der Datenbank haben Spalten, welche das Erstell- bzw. �nderungsdatum aufnehmen. Das �nderungsdatum setzte ich auf der Serverseite, bevor ich den Datensatz speichere. Da ich die gespeicherten Daten nicht erneut lese, stimmt das �nderungsdatum auf dem Client nicht mehr mit dem �nderungsdatum in der Datenbank �berein und somit kann der Datensatz nicht gespeichert werden

Announcement

"Concurrency violation" beim Speichern von Daten

"Concurrency violation" beim Speichern von Daten

Comment

Comment

Comment

Comment