Hallo Tanja,
der Grundstein einer guten Lösung ist eine exakte Problembeschreibung - jedenfalls kann die Qualität der Lösung nicht besser sein als die Qualität der Analyse. Oft ist ein deklarativer Ansatz besser als ein prozeduraler, ganz besonders wenn
SQL im Spiel ist.
In deinen Beiträgen erkenne ich die Tabelle Anfangsdaten A (Wert1, Wert2, ...), zwei Tabellen mit Suchdaten S1 (Test1, Wert1, ...) und S2 (Test2, Wert2, ...), sowie die Tabelle Bearbeitungsdaten B (Test1, Test2, Kanal, TestDatum, ...).
Du hast offensichtlich eine ein-eindeutige Schlüsselabbildung von A.Wert1 nach B.Test1 über S1, wodurch S1.Wert1 neben dem primary key S1.Test1 zum candidate key avanciert. Analoges gilt für S2. Andernfalls könntest du nicht wie gezeigt suchen.
Für jedes Tupel (A.Wert1, A.Wert2) suchst du ein korrespondierendes Tupel (B.Test1, B.Test2) um bei dessen Existenz einige Felder (B.TestDatum) in Abhängigkeit einer Funktion K(B.Kanal, ...) zu verändern. Die Funktion K() hast du nicht genau beschrieben. Wenn es sich dabei nur um verkettete String-Funktionen handelt, dann ist eine Implementierung in
SQL sehr wahrscheinlich möglich. In meinem Beispiel habe ich K() als Null-Test eingesetzt:
SQL-Code:
UPDATE B
SET TestDatum = '2007-07-16'
WHERE Kanal IS NULL
AND EXISTS (
SELECT B.*
FROM A, B, S1, S2
WHERE A.Wert1 = S1.Wert1
AND A.Wert2 = S2.Wert2
AND S1.Test1 = B.Test1
AND S2.Test2 = B.Test2
)
Reverse Engineering ist nicht einfach. Wenn ich deine Anforderungen nicht richtig erkannt habe, dann kannst du sie gerne etwas präzisieren.
Freundliche Grüße