Vidareutvecklar ett befintligt system, och har stött på en hel del varianter av en ganska vanlig grej.
Låt säga att vi har en tabell a, med lite fält b, c, d och ID. ID är primary key.

Vi kan därför göra en INSERT INTO a(b,c,d) VALUES("b", 124, "apa"). Id kommer få ett unikt värde.

Men vilka garantier kan vi då få på ID:t?
Eller, formulerat på ett annat sätt, hur kan vi få fram Id:t efteråt?

Jag har sett en variant som i princip gick ut på att hämta upp den som passade bäst:

SELECT ID FROM a WHERE b = "b" AND c=124 AND d="apa"

Känns mycket otrevligt.

Och ytterligare en som går på "senaste"; låt säga att c ovan är en foreign key.

SELECT ID FROM a WHERE c=124 ORDER BY ID DESC.

Och sen väljer man första.
Känns inte heller helt bra, men om man har en garanti att de alltid ökar, så...


Det mest rimliga är väl att använda databasens "inbyggda sätt" för att få fram Idt?
typ "select @@identity" heter det väl för någon?
Problemet där är ju att vi kommer arbeta mot många olika databassystem.

Eller själv bestämma id:t först. Typ:
ID = SQL(SELECT Max(id) + 1 FROM ...)
eller
ID = SQL(SELECT id FROM ((SELECT id+1 AS ID FROM a) EXCEPT (SELECT id FROM a)) ORDER BY id ASC)
och sen använda det första (eller motsvarande sats med subquery)?

Tror väl inte direkt att jag kommer satsa på att skriva om alla äldre funktioner, men jag tyckte det var märkligt.

@@identity är det bästa sättet att göra det på... För jag antar att du anropar en stored procedure av något slag?

Gör du det innifrån programkoden och många uppdaterar samtidigt så kan du (i extremfall) få fel @@identity tillbaka, dvs identity på det någon annan lade till innan du hann köra ditt kommando.

/Emma

Nej, "jag" anropar inga stored procedures. Det är dock i en transaktion.

Problemet med @@identity är ju att oracle knappast har det?
Och hur är det med access?

Möjligtvis då styra vad det står utifrån databastyp, men det är inte heller särskilt behagligt...

@@IDENTITY fungerar i MSSQL, Access och MySQL. Hur det ligger till i t.ex. Oracle vet jag inte.

Du kan inte få "någon annans" värde med @@IDENTITY om du inte har någon konstig lösning där flera användare delar connection. Om du däremot kör med MAX(ID) osv är det däremot en viss risk att du får fel.

Problemet med @@IDENTITY är om man har en trigger på tabellen som du gör insert i som i sin tur gör en ny insert. I MSSQL finns det en funktion som heter något i stil med scoope_identity som man ska använda istället då.

/Johan

<b>>Om du däremot kör med MAX(ID) osv är det däremot en viss risk att du får fel.</b>
Men inte om det är i en transaktion, väl?

I oracle använder man sekvenser för att skapa unika värden. Det finns funktioner som heter nextval och curval för att skapa nytt värde och hämta aktuellt värde respektive.

Då är ju den metoden mer eller mindre utesluten för mig. Men är det så att primary keys enligt sql-standarden hela tiden ska öka?

<b>Men inte om det är i en transaktion, väl?</b>

Helt rätt, tänkte inte på det...

<b>Då är ju den metoden mer eller mindre utesluten för mig. Men är det så att primary keys enligt sql-standarden hela tiden ska öka?</b>

En vild gissning, jag har svårt att tro det då det är valbart hur serverien ska "se ut" i t.ex. MSSQL.

/Johan

Ok, då kan jag enkelt uttryckt vara ganska säker på att den gamla koden någon gång kommer att smälla...

Tror inte det är aktuellt att försöka ordna upp den heller, alldeles för utspridd kod. Nåväl -- that's life.