Return Primary Key on INSERT statement

[ree32]

I am inserting a record into a table that automatically generates
unique ids (i.e. Primary Key). Is there anyway to return this id. As I
am using this on ASP.net page and I really need the ID to update the
page with the new details.

I think on mysql there is something called LAST_INSERT_ID which does
this.

[Dan Guzman]

So this is an IDENTITY column? In this case, you can use SCOPE_IDENTITY()
in SQL 2000 to return the last identity value generated on the current
connection. With SQL 7 and earlier, you can use @@IDENTITY but the value
will reflect identity values resulting from trigger inserts as well.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"ree32" <re***@hotmail.com> wrote in message
news:76**************************@posting.google.c om...

I am inserting a record into a table that automatically generates
unique ids (i.e. Primary Key). Is there anyway to return this id. As I
am using this on ASP.net page and I really need the ID to update the
page with the new details.

I think on mysql there is something called LAST_INSERT_ID which does
this.

[ree32]

Can you give an example with a set of values and column names as I am
not sure how to use this statement.

"Dan Guzman" <gu******@nospam-online.sbcglobal.net> wrote in message news:<tD*****************@newssvr30.news.prodigy.c om>...

So this is an IDENTITY column? In this case, you can use SCOPE_IDENTITY()
in SQL 2000 to return the last identity value generated on the current
connection. With SQL 7 and earlier, you can use @@IDENTITY but the value
will reflect identity values resulting from trigger inserts as well.

--
Hope this helps.

Dan Guzman
SQL Server MVP

[Dan Guzman]

Here's an example that inserts a row using a proc with the generated value
returned as a single-row, single-column result

CREATE TABLE MyTable
(
MyPK int NOT NULL IDENTITY(1,1)
CONSTRAINT PK_MyTable PRIMARY KEY,
MyData int NOT NULL
)
GO

CREATE PROC MyProc
@MyData int
AS
SET NOCOUNT ON
INSERT INTO MyTable (MyData) VALUES(1)
SELECT SCOPE_IDENTITY()
GO

EXEC MyProc @MyData = 1
GO

--
Hope this helps.

Dan Guzman
SQL Server MVP

"ree32" <re***@hotmail.com> wrote in message
news:76**************************@posting.google.c om...

Can you give an example with a set of values and column names as I am
not sure how to use this statement.

"Dan Guzman" <gu******@nospam-online.sbcglobal.net> wrote in message
news:<tD*****************@newssvr30.news.prodigy.c om>...

So this is an IDENTITY column? In this case, you can use
SCOPE_IDENTITY()
in SQL 2000 to return the last identity value generated on the current
connection. With SQL 7 and earlier, you can use @@IDENTITY but the value
will reflect identity values resulting from trigger inserts as well.

--
Hope this helps.

Dan Guzman
SQL Server MVP

[Damien]

"Dan Guzman" <gu******@nospam-online.sbcglobal.net> wrote in message news:<tD*****************@newssvr30.news.prodigy.c om>...

So this is an IDENTITY column? In this case, you can use SCOPE_IDENTITY()
in SQL 2000 to return the last identity value generated on the current
connection. With SQL 7 and earlier, you can use @@IDENTITY but the value
will reflect identity values resulting from trigger inserts as well.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"ree32" <re***@hotmail.com> wrote in message
news:76**************************@posting.google.c om...

I am inserting a record into a table that automatically generates
unique ids (i.e. Primary Key). Is there anyway to return this id. As I
am using this on ASP.net page and I really need the ID to update the
page with the new details.

I think on mysql there is something called LAST_INSERT_ID which does
this.

Can you help me - I'm starting to think I'm going insane:

Last year, after spending several days trying to debug a few stored
procedures, we stumbled accross a bug in SQL 7 where @@IDENTITY
returned the wrong value if the table you'd just inserted into had a
self-referencing foreign key.

So I went through the stored procedure generator (code and sp
generator to create our data access layer) and added a whole load of
defensive coding in that detected that it was running on SQL 7 and
"corrected" the return value by subtracting the number of self-ref
foreign keys. This all worked fine for a while, and then stopped
working (being in error on the low side now instead) so we removed
this code, and everything has been fine since.

My only question is, does anyone know when/what corrected this bug,
since I cant seem to find it in any of the patch documents?

As a side note to the OP, who Asked how to use the @@IDENTITY, do the
following:

INSERT INTO tblBlah1 (Col1,Col2,Col3) VALUES (Val1,Val2,Val3);

SELECT @@IDENTITY

(If you want to have it returned in a result set of one row/one
column) or

SET @Variable = @@IDENTITY

(If you want to store the value in a variable)

[Dan Guzman]

> Last year, after spending several days trying to debug a few stored

procedures, we stumbled accross a bug in SQL 7 where @@IDENTITY
returned the wrong value if the table you'd just inserted into had a
self-referencing foreign key.
This looks like the bug described in MSKB 322818
<http://support.microsoft.com/default.aspx?scid=kb;en-us;322818>.
So I went through the stored procedure generator (code and sp
generator to create our data access layer) and added a whole load of
defensive coding in that detected that it was running on SQL 7 and
"corrected" the return value by subtracting the number of self-ref
foreign keys. This all worked fine for a while, and then stopped
working (being in error on the low side now instead) so we removed
this code, and everything has been fine since.
The work-around suggested in the article is to remove the self-referencing
foreign key(s) rather than manually adjust the value returned by @@IDENTITY.
You can use an insert trigger to enforce referential integrity instead.
This way, you won't have to change your code if/when the bug is fixed in SQL
7 or you upgrade to SQL 2000.
My only question is, does anyone know when/what corrected this bug,
since I cant seem to find it in any of the patch documents?

Particularly with hotfixes, bugs may get addressed (or introduced) without
accompanying documentation and this may happen with service packs as well.
This is why one should regression test fixes before applying to production.

I don't have a SQL 7 box handy to test this on but I can try to find out
more information. What service pack/patch level are you running?

--
Hope this helps.

Dan Guzman
SQL Server MVP

[ree32]

So you cannot use these SQL statements from ASP.net pages. i.e you
have to create the procedures on the SQL server?

"Dan Guzman" <gu******@nospam-online.sbcglobal.net> wrote in message news:<vr*****************@newssvr11.news.prodigy.c om>...

Here's an example that inserts a row using a proc with the generated value
returned as a single-row, single-column result

CREATE TABLE MyTable
(
MyPK int NOT NULL IDENTITY(1,1)
CONSTRAINT PK_MyTable PRIMARY KEY,
MyData int NOT NULL
)
GO

CREATE PROC MyProc
@MyData int
AS
SET NOCOUNT ON
INSERT INTO MyTable (MyData) VALUES(1)
SELECT SCOPE_IDENTITY()
GO

EXEC MyProc @MyData = 1
GO

--
Hope this helps.

Dan Guzman
SQL Server MVP

[Dan Guzman]

> So you cannot use these SQL statements from ASP.net pages. i.e you

have to create the procedures on the SQL server?
You can also run the INSERT/SELECT script directly from your code:

SET NOCOUNT ON
INSERT INTO MyTable (MyData) VALUES(1)
SELECT SCOPE_IDENTITY()

--
Hope this helps.

Dan Guzman
SQL Server MVP

"ree32" <re***@hotmail.com> wrote in message
news:76**************************@posting.google.c om... So you cannot use these SQL statements from ASP.net pages. i.e you
have to create the procedures on the SQL server?

"Dan Guzman" <gu******@nospam-online.sbcglobal.net> wrote in message
news:<vr*****************@newssvr11.news.prodigy.c om>...

Here's an example that inserts a row using a proc with the generated
value
returned as a single-row, single-column result

CREATE TABLE MyTable
(
MyPK int NOT NULL IDENTITY(1,1)
CONSTRAINT PK_MyTable PRIMARY KEY,
MyData int NOT NULL
)
GO

CREATE PROC MyProc
@MyData int
AS
SET NOCOUNT ON
INSERT INTO MyTable (MyData) VALUES(1)
SELECT SCOPE_IDENTITY()
GO

EXEC MyProc @MyData = 1
GO

--
Hope this helps.

Dan Guzman
SQL Server MVP

[Damien]

"Dan Guzman" <gu******@nospam-online.sbcglobal.net> wrote in message news:<zu*****************@newssvr11.news.prodigy.c om>...

Last year, after spending several days trying to debug a few stored
procedures, we stumbled accross a bug in SQL 7 where @@IDENTITY
returned the wrong value if the table you'd just inserted into had a
self-referencing foreign key.

This looks like the bug described in MSKB 322818
<http://support.microsoft.com/default.aspx?scid=kb;en-us;322818>.

It was indeed this bug. I was just curious if anyone knew when/where
it was fixed, but I'm not going to worry about it too badly
(especially since I lost SA/DBO access on most of the boxes recently,
so dont have access to nearly so much information :-()

[ree32]

Thank you so much. IT works!!!

"Dan Guzman" <gu******@nospam-online.sbcglobal.net> wrote in message news:<WX*****************@newssvr11.news.prodigy.c om>...

So you cannot use these SQL statements from ASP.net pages. i.e you
have to create the procedures on the SQL server?

You can also run the INSERT/SELECT script directly from your code:

SET NOCOUNT ON
INSERT INTO MyTable (MyData) VALUES(1)
SELECT SCOPE_IDENTITY()

--
Hope this helps.

Dan Guzman
SQL Server MVP

[Dan Guzman]

I'm glad I was able to help you out.

--
Dan Guzman
SQL Server MVP

"ree32" <re***@hotmail.com> wrote in message
news:76**************************@posting.google.c om...

Thank you so much. IT works!!!

"Dan Guzman" <gu******@nospam-online.sbcglobal.net> wrote in message
news:<WX*****************@newssvr11.news.prodigy.c om>...

> So you cannot use these SQL statements from ASP.net pages. i.e you
> have to create the procedures on the SQL server?

You can also run the INSERT/SELECT script directly from your code:

SET NOCOUNT ON
INSERT INTO MyTable (MyData) VALUES(1)
SELECT SCOPE_IDENTITY()

--
Hope this helps.

Dan Guzman
SQL Server MVP