Det kan inte fungera så. Tänk på:
- program ett, du öppnar en transaktion och infogar i en tabell FOO som har en autoinc primärnyckel (godtyckligt säger vi att den får 557 för sitt nyckelvärde).
- Program två startar, det öppnar en transaktion och infogas i tabell FOO och får 558.
- Programmera två inlägg i tabellen BAR som har en kolumn som är en främmande nyckel till FOO. Så nu ligger 558 både i FOO och BAR.
- Program två börjar nu.
- Program tre startar och genererar en rapport från tabell FOO. 558-posten skrivs ut.
- Efter det rullas program ett tillbaka.
Hur tar databasen tillbaka 557-värdet? Går den in i FOO och minskar alla andra primärnycklar större än 557? Hur fixar det BAR? Hur raderar den 558:an som är utskriven på rapportprogrammets tre utdata?
Oracles sekvensnummer är också oberoende av transaktioner av samma anledning.
Om du kan lösa det här problemet konstant, är jag säker på att du kan tjäna mycket pengar på databasfältet.
Nu, om du har ett krav att ditt automatiska inkrementfält aldrig har luckor (säg för revisionssyften). Då kan du inte återställa dina transaktioner. Istället måste du ha en statusflagga på dina poster. Vid första insättningen är postens status "Incomplete" sedan startar du transaktionen, gör ditt arbete och uppdaterar statusen till "compete" (eller vad du behöver). När du sedan binder dig är skivan live. Om transaktionen rullar tillbaka finns den ofullständiga posten fortfarande kvar för granskning. Detta kommer att orsaka dig många andra huvudvärk men är ett sätt att hantera revisionsspår.