Jag har två tabeller "orderhuvud" och "orderrad" (en order har ett orderhuvud men kan ha flera orderrader). När det läggs in en order i dessa, så ska det automatiskt kollas vissa värden på orderhuvudet. Är allt ok så ska det skapas en kopia i tabellerna "orderhuvudOK" och "orderradOK". Sedan ska aktuell order tas bort från tabellerna "orderhuvud" och "orderrad". Borttaget ska ske även om ordern inte är ok.

Det känns ju ganska självklart att skapa en trigger på tabellen "orderhuvud" som först kör testen, sedan ev. skapar nödvändiga poster i "orderhuvudOK" och "orderradOK". Sist så tar den bort ordern från "orderhuvud" och "orderrad".

Problemen jag får:
1. Triggern på "orderhuvud" kickar igång innan några poster i "orderrad" hunnit skapas. Lösningen är INTE att skriva in raderna i "orderrad" först. Då blir det problem med främmande nyckel (FK) mot "orderhuvud".
2. Triggern körs innan transaktionen är avslutad. Så att radera posterna i "orderhuvud" och "orderrad" blir svårt. När jag försöker radera orderrader så blir det FK-problem. När jag enbart försöker radera orderhuvudet så visar det sig att det inte blir raderat. Antagligen för att transaktionen inte är commitad.

Någon som har någon idé hur jag ska angripa problemet? Helst skulle jag vilja undvika att ha en trigger även på tabellen "orderrad", då jag vill hålla ihop koden och behandla "allt eller inget" av ordern.

1. I min synvinkel är det inte rätt användning av en trigger. Triggers ligger i allmänhet på rad-per-rad.
2. Det är inte riktigt vettigt att orderhuvud/orderrad bara är någon slags väntetabell.

Jag skulle snarare ha gjort det i stil med:
1. Sköt urvalet helt och hållet via kod.
eller
2. Använd constraints på orderhuvudet vid insert direkt i orderhuvud. Om orderhuvudet inte är korrekt så läggs inte huvudet in, och på grund av foreign keys så kan du inte lägga in orderrader då heller.

Ett sista alternativ skulle vara att du gör som du gör nu, men ha ytterligare en tabell avsedd för triggern, och som läggs in i sist.

Jag håller med med dig, orderhuvud/orderrad används bara temporärt och man skulle nog vilja göra det på annat sätt. Men det är som det är och ligger utanför det område som jag kan påverka.
Jag kan inte heller lägga några constraints på dessa tabeller, eftersom man måste tillåta felaktiga order att lagras. De ska behandlas på liknande sätt som de som är ok (vilket jag hade utelämnat i den ursprungliga beskrivningen).

Om ingen annan har någon idé så får jag gå på din sista variant.
D.v.s. när någon har skrivit en order i orderhuvud/orderrad, så måste de skicka ett meddelande på något sätt. T.ex. lägga in ordernumret i en tredje tabell.
Det är inte exakt vad jag vill, eftersom det kräver att jag involverar externa personer. Men...

Organisationer... ;-)

Nåja. Kan du inte påverka vare sig koden som lägger in eller databasens struktur, och måste vänta tills alla orderrader är inlagda, tror jag inte du har mycket val.

Det här är ett typexempel på hatsituationer i större organisationer. Är något fel ska det fanimej rättas till, det blir billigare än horder av fullösningar.