ID opvragen van toegevoegde record

[Urk]

Als opvolging op dit topic:
[rml][ SQL/ASP] sleutel van nieuwe record achterhalen[/rml]

Ik doe het volgende:

ASP:

runSQL = "INSERT INTO tabelnaam(testveld1) values ('" & Request.Form("test") & "')"
DBCon.Execute(runSQL)

SQL = "SELECT @@IDENTITY AS useridentifier FROM tabelnaam"
Set RS = DBCon.Execute(SQL)

Response.Write RS("useridentifier")

RS.Close
Set RS = nothing

Ik haal dus van het nettoegevoegde record het ID op!
Mijn vraag hierop is alleen: gaat dit wel goed als bijv 2 users TEGERLIJKERTIJD (ook als ik dit bijna onwaarschijnlijk) een record toevoegen.
Het opvragen van die ID zit namelijk niet indezelfde thread toch?

ASP:

Zoals bij 
RS.AddNew
 RS("naam") = naam
RS.Update

unique_id = RS("id")
RS.Close
Set RS = nothing

Dit zit natuurlijk in dezelfde RS, deze kan dus neem ik aan geen andere ID krijgen doordat de cursor nog in dat record staat.

Ik wil het echter op de eerste methode doen maar blijft de cursor dan wel in het record? Krijg ik dus niet de ID van bijv het record wat er net tussenin nog snel is toegevoed??

Mijn dank is groot

[whoami]

De select @@identity heeft het laatst geinserte id terug van deze sessie, maw, het gaat goed als 2 users tegelijk een record toevoegen. Iedere user heeft nl. zijn eigen sessie.

Let wel op 'het laatst geinserte id'. Stel dat je een trigger hebt die uitgevoerd wordt bij een insert, en die trigger zorgt ervoor dat er in een andere tabel nog een record wordt toegevoegd, dan kun je wel eens ongewenste resultaten bekomen.

Voor meer info, zie ook de SQL Server Books online.

[ Voor 44% gewijzigd door whoami op 14-04-2003 17:02 ]

[Urk]

Ja, OK, iedere user heeft zijn eigen sessie. Maar niet zijn eigen DB record, ik bedoel alles komt uit dezelfde tabel.

Dus is dat dan wel zeker?

[_Thanatos_]

@@IDENTITY werkt volgens Books Online "per-connection" en is dus veilig om in een multi-user omgeving te gebruiken. Bovendien hoef je bij mijn weten de tabel niet eens mee te geven.

SQL:

SELECT @@IDENTITY

Dit is meer dan voldoende.

[whoami]

Urk schreef op 14 april 2003 @ 17:02:
Ja, OK, iedere user heeft zijn eigen sessie. Maar niet zijn eigen DB record, ik bedoel alles komt uit dezelfde tabel.

Dus is dat dan wel zeker?

Ja. Iedere user heeft ook z'n eigen sessie. Die @@identity houd -zoals ik al gezegd heb- geen rekening met de tabel.
(Zie ook m'n andere opmerkingen, en kijk eens in de books online (help) van Sql Server).
Je hebt ook nog een aantal andere functies om het laatst geinserte id te verkrijgen, zoals ident_current() of iets dergelijks.

_Thanatos_ schreef op 14 April 2003 @ 17:03:
Bovendien hoef je bij mijn weten de tabel niet eens mee te geven.

SQL:

SELECT @@IDENTITY

Dit is meer dan voldoende.

Ben je dat zeker?
Ben je zeker dat je dan geen syntax errors krijgt?
Een SELECT statement verwacht nl. altijd een FROM clausule.

* whoami gaat ff testen.

Idd, in Sql Server hoef je geen FROM clause op te geven.

[ Voor 43% gewijzigd door whoami op 14-04-2003 17:08 ]

[_Thanatos_]

een SELECT statement *vereist* geen FROM clause. Kijk maar in de syntax in Books Online.

Je kunt immers ook dit soort dingen doen:

SQL:

SELECT 1
SELECT GETDATE()
SELECT 'blabla'

/edit
die andere mogelijkheden om de inserted ID op te vragen waren geloof ik per-user en server-wide. No go dus, lijkt me.

[ Voor 27% gewijzigd door _Thanatos_ op 14-04-2003 17:36 ]

[Gert]

Officieel gebruik je daar een lege tabel voor, met dus een FROM ding.

[whoami]

_Thanatos_ schreef op 14 April 2003 @ 17:34:
een SELECT statement *vereist* geen FROM clause. Kijk maar in de syntax in Books Online.

Je kunt immers ook dit soort dingen doen:

SQL:

SELECT 1
SELECT GETDATE()
SELECT 'blabla'

Dat is dan specifiek MS implementatie hoor.

In Oracle is een FROM clause verplicht.

die andere mogelijkheden om de inserted ID op te vragen waren geloof ik per-user en server-wide. No go dus, lijkt me.

SCOPE_IDENTITY, IDENT_CURRENT, and @@IDENTITY are similar functions in that they return values inserted into IDENTITY columns.

IDENT_CURRENT is not limited by scope and session; it is limited to a specified table. IDENT_CURRENT returns the value generated for a specific table in any session and any scope. For more information, see IDENT_CURRENT.

SCOPE_IDENTITY and @@IDENTITY will return last identity values generated in any table in the current session. However, SCOPE_IDENTITY returns values inserted only within the current scope; @@IDENTITY is not limited to a specific scope.

For example, you have two tables, T1 and T2, and an INSERT trigger defined on T1. When a row is inserted to T1, the trigger fires and inserts a row in T2. This scenario illustrates two scopes: the insert on T1, and the insert on T2 as a result of the trigger.

Assuming that both T1 and T2 have IDENTITY columns, @@IDENTITY and SCOPE_IDENTITY will return different values at the end of an INSERT statement on T1.

@@IDENTITY will return the last IDENTITY column value inserted across any scope in the current session, which is the value inserted in T2.

SCOPE_IDENTITY() will return the IDENTITY value inserted in T1, which was the last INSERT that occurred in the same scope. The SCOPE_IDENTITY() function will return the NULL value if the function is invoked before any insert statements into an identity column occur in the scope.

IDENT_CURRENT is idd een no-go in dit geval.