find indeks på indsat post i db

select indeks from tabel where indeks = last_insert_id()

Kan du ikke bruge TOP 1 * ? ? ?

Det tager den med det højeste ID, hvis du sorterer efter id!

.

Jeg har tidligere brugt som netsrac foreslog, og det virker helt ok

nej nej! også alt for usikkert!
Hvis to bruger submitter samme INSERT INTO på samme tidspunkt, er muligheden for at den ene bruger får den andens indeks alt for stor.

Mit spørgsmål lyder på om der ikke findes en metode hvorpå man finder indeks i det øjeblik den bliver oprettet????

http://activedeveloper.dk/aspdigital/kapitel2/sql_identity.asp

Ikke med mySQL, da det ikke er til at få den til at æde en transktion, så skal du ud i og lave en Application.Lock og Application.Unlock uden om koden.

Sandsynigheden for at 2 rammer det samme ID er dog MEGET lille, jeg har brugt ovenstående med succes og aldrig er der en der har ramt forkert.

Men Max() metoden er dog usikker, da mySQL godt kan finde på at sætte ind på tomme pladser hvor man har slettet en record.

keysersoze >> Sjovt nok virker det der kun på Access og MSSQL.

keysersoze -> Virker denne også i MySQL ???

Set rsIdentity = myConn.Execute("SELECT @@IDENTITY as NewID FROM TESTBASE")
Response.Write rsIdentity("NewID")

hov - havde ikke set det var mysql :)

netsrac -> Jeg vil være lidt ked af at skulle lås min db hver gang, det kan ikke forbedre min response tid på serveren.

Til hvor mange bruger har du benyttet. "select indeks from tabel where indeks = last_insert_id()"???

Jeg kommer til at have mange brugere (rigtig mange)!

Jeg har brugt det hvor der har været 100 samtidige brugere på sitet, men det kan også være jeg bare har været bragende heldig.

Men hvis du vil have det helt rigtigt, så du er 100% sikker på at det ikke går galt, bliver du nok nød til at vælge en anden DBMS som understøtter transaktioner, f.eks. MS SQL eller Oracle, selvom det er min mening at de er sløve i forhold til mySQL´en.

netsrac -> Ved du om den nye MySQL (i beta) understøtter transactions?

...jeg savner også at MySQL understøtter inline views... :-)

*\ om ikke andet så tak for svaret, jeg tror jeg vælger at låse, for skulle tilfældet være ude med to simultane brugere, så er den helt gal.

Jeg har endnu ikke haft tid til at kigge på den nye mySQL, men jeg tror ikke de er nået så langt endnu. Ja views har vi jo manglet i lang tid, men det kommer vel engang, men man kan jo heller ik forvente alverden af en gratis DBMS.

Hvis du gerne vil undgå at låse så er en mulig løsning at oprette et talfelt i tabellen med plads til Session.SessionID så er nedenstående linie pludselig 100% sikker. !

"SELECT MAX(indeks) FROM tabel where SessionID=" & Session.SessionID

Jeg har haft lignende flerbruger problemer inde på livet i 10 år og ville ikke tøve med at anvende denne løsning hvis transaktionstyring ikke er tilgængelig.

coltau -> Giver en dårlig normalisering, idet at kolonnen i db'en er uoverflødig. Ellers tak!

Når jeg har ovenstående problem i access, så har jeg sommetider gjort det at jeg har dannet en stræng på 50 tilfældige karektere, denne gemme jeg så, og smider den ned i databasen, i et felt der er lavet til dette, herefter er det så bare at søge i databasen på denne gemte streng, og så finde det idnummer denne har, og så er mit postulat at det er meget usandsynlig at en anden skulle få dannet samme streng inde for de "par sek." det tager at oprette strengen, gemme denne i db, hente id, og så evt slette strengen igen i tabelen

Jeg er godt klar over at dette ikke er en særlig køn måde at lave sådan noget på, men det virker hvergang !

sth >> Hvis man virkelig skal ud i den løsning så er coltau´s løsning 100 gange bedre, Sessionidet er der allerede, unikt for hver bruger på websitet, så hvorfor ikke bruge det ?

Det kan jeg da kun være enig i, men den kendte jeg ikke, og skrev derfor hvad jeg så havde brugt.

Så er det jo godt at man kan komme på eksperten og lære noget nyt :)