UPDATE mit WHERE und JOIN

[Codehunter]

Hallo!

Ich habe jetzt schon diverse Beispiele im Netz durchexerziert, doch keines davon scheint zu funktionieren (oder ich bin zu doof dazu ^^). Folgendes Problem:

Ich habe eine Stored Procedure MYPROC, welche eine Datenmenge zurückgibt:
SELECT ID FROM MYPROC(1234);

Code:

ID
====
1
3
4
6
8
10
12
13
15

Nun habe ich eine Tabelle T, in welcher ich das Feld XYZ updaten muss, wenn das Feld NUMMER einer der Zeilen des obigen Ergebnisses entspricht. Das Ganze soll in einem clientseitigen Query passieren, nicht in einer weiteren StoredProc.

Folgendes habe ich schon probiert:
UPDATE T SET XYZ='Test' WHERE EXISTS (SELECT 1 FROM MYPROC(1234) MP WHERE T.NUMMER=MP.ID); Hier läuft sich die Abfrage tot.

FOR SELECT ID FROM MYPROC(1002) MP INTO ID AS CURSOR C DO UPDATE T SET XYZ='Test' WHERE CURRENT OF C Hier bekomme ich ein Unknown Statement "FOR".

MERGE INTO T USING (SELECT ID FROM MYPROC(1234)) MP ON MP.ID=T.NUMMER WHEN MATCHED THEN UPDATE SET T.XYZ='Test'; Hier bekomme ich einen Deadlock.

Das sind so die Beispiele, die ich im Netz finden konnte. Und nu seh ich nur noch

Grüße
Cody

[mkinzler]

SQL-Code:

UPDATE T set XYT='TEST' where T.NUMMER in 
  (SELECT ID FROM MYPROC(1234));

[Codehunter]

Zitat von mkinzler:

SQL-Code:

UPDATE T set XYT='TEST' where T.NUMMER in 
  (SELECT ID FROM MYPROC(1234));

Deadlock

So langsam glaube ich, dass Tabelle T in ihrem ganzen Rattenschwanz an Triggern wiederum einen Select auf sich selbst macht und dadurch der Deadlock entsteht. Das ist dann aber wohl ein Fall für unseren Datenbank-Guru.

[mkinzler]

Was macht die Stored Procedure? Greift die möglicherweise auf die selbe Tabelle zu?

[joachimd]

Du kannst die Ergebnisse evtl auch in eine (temp) Tabelle abkippen und dann von dort selektieren:

Code:

SELECT ID INTO #mytmp FROM MYPROC(1234);
UPDATE T set XYT='TEST' where T.NUMMER in (SELECT ID FROM #mytmp); 
DROP TABLE #mytmp;

[jobo]

Vielleicht spuckt die Proc auch die gleichen ID mehrfach aus. Entweder Algo prüfen oder umstellen auf

Code:

select distinct id from myproc(123);

Ich weiß nicht, ob fb das kann, aber vielleicht wird auch in der Proc explizit mit Transaktionen / Savepoints gearbeitet, wäre auch ein Killerfaktor.

[mkinzler]

Zitat:

Vielleicht spuckt die Proc auch die gleichen ID mehrfach aus

Das sollte grundsätzlich kein Problem sein.

Bei FireBird laufen (architekturbedingt) auch Selects innerhalb von Transaktionen.

[Codehunter]

Problem geklärt. Es liegt tatsächlich an Triggern.