Wie kann die Reihenfolge der Ausführung der Update-Abfrage gesteuert werden?

Question

Ich habe eine Tabelle in MS SQL 2005 und tun möchte:

update Table 
set ID = ID + 1 
where ID > 5 

Und das Problem ist, dass ID Primärschlüssel ist und wenn ich dies tun habe ich einen Fehler, denn wenn diese Abfrage Reihe kommt mit ID 8 versucht es den Wert auf 9 zu ändern, aber es gibt eine alte Zeile in dieser Tabelle mit dem Wert 9 und es gibt eine Constraint-Verletzung.

Daher möchte ich die Update-Abfrage steuern, um sicherzustellen, dass es in absteigender Reihenfolge ausgeführt wird.

Also nein für ID = 1,2,3,4 und so weiter, sondern ID = 98574 (oder sonst) und dann 98573, 98572 und so weiter. In dieser Situation gibt es keine Einschränkung der Beschränkung.

So, wie Reihenfolge der Updateausführung zu steuern? Gibt es einen einfachen Weg, dies programmatisch zu realisieren?

Answer 1

Transact SQL verschiebt Einschränkungsprüfung, bis die Anweisung abgeschlossen ist.

Deshalb ist diese Abfrage:

UPDATE mytable 
SET  id = CASE WHEN id = 7 THEN 8 ELSE 7 END 
WHERE id IN (7, 8) 

wird nicht scheitern, obwohl es id ‚s 7 und 8 Swaps.

Es scheint, dass einige doppelte Werte übrig sind, nachdem Ihre Abfrage beendet wurde.

Answer 2

Versuchen Sie folgendes:

update Table 
set ID = ID * 100000 + 1 
where ID > 5 

update Table 
set ID = ID/100000 
where ID > 500000 

Answer 3

die Klammer nicht Vergessen Sie ...

Update Tabelle Set ID = (ID * 100000) + 1 wo ID> 5

Wenn Die IDs werden hier zu groß, Sie können immer eine Schleife verwenden.

Answer 4

Persönlich würde ich ein ID-Feld auf diese Weise nicht aktualisieren, ich würde eine Arbeitstabelle erstellen, die die alte zu neue Tabelle ist. Es speichert beide IDs und dann werden alle Updates von diesem gemacht. Wenn Sie keine Kaskadenlöschung verwenden (was Ihre Tabellen für eine lange Zeit sperren könnte), dann beginnen Sie mit den Kindtabellen und arbeiten Sie weiter, andernfalls beginnen Sie mit der PK-Tabelle. Tun Sie dies nicht, es sei denn, Sie befinden sich im Einzelbenutzermodus oder Sie können einige unangenehme Datenintegritätsprobleme bekommen, wenn andere Benutzer Dinge ändern, während die Tabellen nicht konsistent sind.

PKs sind nichts, um mit Änderungen herumzualbern und wenn überhaupt möglich sollte nicht geändert werden.

Bevor Sie auf diese Weise Änderungen an Produktionsdaten vornehmen, sollten Sie eine vollständige Sicherung durchführen. Dies zu verkomplizieren, kann Sie Ihren Job kosten, wenn Sie sich nicht erholen können.