problem med autonummer i tabel

Hvis det er den funktionalitet, så skal du ikke bruge autonummerering. I stedet skal du manuelt tildele værdien via en select max(TabelID)+1.

Ved delete skal du lige lave:

Update tabel set nrfelt = nrfelt - 1
where nrfelt > @slettetnr

Database har det med at holde styr på de autoincrement
felter og opdatere dem udfra deres interne info.

Jeg har set det samme i Access.

Men hvorfor er det et problem ?

Skal du ikke bare have en unik nøgle ?

Hvis du virkeligt vil have dem fortløbende så kan
du bruge de 2 forrige svar.

MEN du skal have styr på dine transaktioner ellers
så kan det gå meget galt med simultane opdateringer.

Ideen med et autonummereringsfelt er, at det altid er unikt, så det kan bruges som fremmednøgle i andre tabeller.

Hvad er begrundelsen for, at der skal tildeles en højere end det sidst brugte?

grunden er at jeg skal kunne håndtere flere brugere der samtiddig opdatere samme felt i min database, kun første bruger skal have lov, anden skal have fejl!
Jeg bruger autonemmerering for netop at undgå at der kommer flere ID der er identiske, hvilket der gør ved max(tabelID)+1 metoden, da de 2 brugere samtiddig skriver til databasen. men hvis man laver autonummerering, kommer der altdi et unikt ID, hvilket jeg bagefter gerne vil chekke om med nummeret af Id's der var lige inden de opdaterede, og hvis det så er højere end 1, så nægter jeg opdateringen. Hvad gør en Flush table funktion?? kan det ikke resette de interne info i DB'en så den altid vælger det højeste ID og tildeler en højere??

mvh kledal

Er det samme felt på samme post, de vil opdatere samtidig? Eller er det samme felt i forskellige poster?

select max(TabelID)+1 og insert kan godt løse problemet,
hvis men også kun hvis tabellen er låst mellem de 2
statements.

jeg låser tabellen og det virker stadig ikke!

Og det er alle felterne i samme tabel, der skal opdateres!
Det handler om nogle rapporter, som har et versionsnummer (det er dette der skal stige med 1) og de har en ID, denne er ikke unik. Når rapporten bliver opdateret, bliver foregående versionsnummer, sat til 'tidligere' i status-feltet, og der indsættes en ny rapport med samme ID, og et versionsnummer der er en højere end foregående version. Når 2 brugere gør dette samtiddig, oprettes der 2 rapporter med samme versionsnummer. For at omgå dette oprettede jeg et nyt felt (ekstra_id) dette er autonummereret, og jeg tjekker så om det ekstra_id nummer brugerne har med når de skal ind og oprette en ny rapport, er mere end 1 lavere end det nye nummer som DB'en automatisk giver dem er. Hvis det er det, slettes den post de netop har indsat i DB'en igen, men dette giver det problem at autonummereringen allerede har brugt det nummer som er en gang større en gang før. Og næste gang sættes det blot en højere end sidst. Derfor vil jeg høre om man kan FLUSHE Tabellen og hvad denne funktion gør!!

for jeg skal på en eller anden måde resette DB'en.

håber dette er forståeligt nok :-)
mvh kledal

Hvis tabellen er låst hvordan kan det så gå galt ?

Jeg tror du har forkert transaction isolation level
i databasen !

fordi når tabellen er låst, så venter den bare med at indsætte den næste værdi!

Jeg foreslår en insert trigger der automatisk finder max og sætter den nye version til max+1. På den måde behøver du ikke låse databasen.

jeg har gjort det på en anden måde.
har omgået det ved kun at tillade en bruger at redigere i en rapport ad gangen!