Med DB2 version 8 fulgte en masse ny funktionalitet. En af de godt skjulte faciliteter er muligheden for at få returneret værdien af diverse indbyggede funktioner, der benyttes i en INSERT. Hidtil har man været tvunget til at udføre et SQL SET kald før INSERT for at få fat i disse værdier, men det er slut nu. Hidtil har man også været afskåret fra at kunne få værdien af kolonner med DEFAULT eller ROWID oplyst. Det samme gælder for de såkaldte identity columns, som jeg dog ikke håber, du har rodet dig ud i.

Rigtig mange installationer benytter en timestamp kolonne som unik nøgle på deres tabeller. For at kunne genbruge den unikke nøgle som fremmednøgle på andre tabeller, laver man først et EXEC SQL SET :keyColValue = CURRENT TIMESTAMP kald og herefter en INSERT, men nu kan det gøres i et eneste hug:

SELECT keyCol, col3
INTO :keyColValue, :col3value
FROM FINAL TABLE
( INSERT INTO myTable (keyCol, col1, col2, col3)
  VALUES(CURRENT TIMESTAMP, :col1, :col2, DEFAULT)
)

Det er da let og elegant. Hvis nu COL3 i ovenstående eksempel er oprettet med WITH DEFAULT 'XXX', så vil hostvariablen COL3VALUE efter kaldet indeholde værdien 'XXX'. Ved at angive DEFAULT får man altå returneret værdien af kolonner, som man måske helt ville udelade af sin VALUES liste, som eksempelvis identity columns og ROWID kolonner. Men hvad hvis nu INSERT'en fejler på grund af, at current timestamp alligevel ikke var unik (en anden parallel INSERT fik samme timestamp, en ikke ualmindeligt forekommende hændelse nu om dage), ja så får man en SQLCODE -803, selv om det er et SELECT-kald, der er udstedt.

Nu vil du sikkert gerne vide, om det har nogen effekt at lave en SET med efterfølgende INSERT om. Og det har det, selv om effekten er begrænset. Du sparer den tid det koster DB2 at udføre et ekstra SQL-kald (SET kaldet), men til gengæld er INSERT blevet en lille smule dyrere, da der skal returneres data til dit program, men alt i alt er det en smule mere effektivt at lave en SELECT FROM FINAL TABLE i stedet.