Een ODBC-tracering onthult dat Access inderdaad SELECT @@IDENTITY
. aanroept (in tegenstelling tot SCOPE_IDENTITY()
) na het invoegen van de rij in de SQL Server-gekoppelde tabel:
Database1 e00-1490 EXIT SQLExecDirectW with return code 0 (SQL_SUCCESS)
HSTMT 0x00000000004D6990
WCHAR * 0x000000000F314F28 [ -3] "INSERT INTO "dbo"."Table1" ("txt") VALUES (?)\ 0"
SDWORD -3
...
Database1 e00-1490 EXIT SQLExecDirectW with return code 0 (SQL_SUCCESS)
HSTMT 0x00000000004D6990
WCHAR * 0x000007FED7E6EE58 [ -3] "SELECT @@IDENTITY\ 0"
SDWORD -3
Bovendien lijkt dit gedrag af te hangen van het ODBC-stuurprogramma dat wordt gebruikt, aangezien een vergelijkbare test met MySQL Connector/ODBC aantoont dat Access de bijbehorende MySQL-functie niet aanroept LAST_INSERT_ID()
na het invoegen van een rij in een gekoppelde MySQL-tabel.
Aangezien Access belt SELECT @@IDENTITY
, moeten we onze trigger als volgt wijzigen (bron: hier
) om de @@IDENTITY-waarde terug te zetten naar de oorspronkelijke waarde
create trigger mytable_insert_trigger on mytable for insert as
declare @identity int
declare @strsql varchar(128)
set @[email protected]@identity
--your code
--insert into second table ...
--your code
set @strsql='select identity (int, ' + cast(@identity as varchar(10)) + ',1) as id into #tmp'
execute (@strsql)