@@IDENTITY vid olika conn-objekt

@@IDENTITY i Access är beroende av att man använder samma connection-objekt som vid uppdateringen, um?

Jao.

Tackar. :)

Då har jag ett problem.

Läckert.

På vilket sätt?

Jag använder två funktioner i applikationen, som jag alltid gör om jag inte bygger komponent:

• getConn
• execSQL

getConn instansieras på nytt varje gång jag kör något genom execSQL, vilket innebär att den även förstörs när execSQL är klar.

There is your problem. ;)

Kan du se till att ha ett unikt id för varje session som gör insert, så lagra det i tabellen. Sedan kan du plocka fram med SELECT MAX det räknarvärde som är högst, där sessions-id är korrekt.

Mvh,

Jo, jag vet att man kan göra så, men jag vill vara 100% säker på att det inte blir inkonsistens (?) om någon mikklar i databasen på annat håll samtidigt.

Jag kör en 'SELECT TOP 1 .... ORDER BY id DESC' just nu.

Kan du inte bara slänga med någon sorts sessionsid?

/me fails to see problem.

Jo, men id är givetvis en räknare.

Problemet är att (visserligen ganska liten) någon uppdaterar precis innan en annan användare har hunnit få tillbaks sitt id från databasen. Då får denna fel id, eftersom hans då ju inte är sist längre. Du måste ju känna igen det.

Vad menar du med att slänga med sessionsid? I tabellen då eller och jämföra med vid hämtningen av id:t?

Det jag menar:

mittSessionsidEllerLiknande = Session.SessionID
ExecSQL ("Insert into tabell (bla, bla2, ControlID) values ('bla', 'bla', " & mittSessionsidEllerLiknande)
set rs = ExecSQL("Select top 1 id from tabell where ControlID = " & mittSessionsidEllerLiknande)
insertid = rs(0)

Missförstår vi varandra? Även om någon hinner med en insert emellan, så spelar inte det någon roll, eftersom de har olika kontrollsiffror.

Mvh,

Jo, jag fattade vad du menade. ;) Nu fattar jag mer.

Det är en lösning, faktiskt. Tackar. :D

Sure thing.

Glad att du förstod min ful-pseudo. ;)

Mvh,