You won't have to worry about inserts goofing you up with @@identity - as
it's returned with the single query you're doing (or rather the stored
procedure), it's basically one big step as far as the db server is
concerned. Sorta like the "you don't take your hand off your chess piece
until you're ready to commit to the move" deal.
> -----Original Message-----
> From: Ken M. Mevand [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 24, 2000 9:46 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Avoiding using the MAX function
>
>
> hi,
> i have some questions on @@IDENTITY. it is possible that
> another insert
> could have taken place between the first insert and the
> select @@identity
> statement. is there a way to prevent this, maybe locking ???
>
> but since @@identity it is a global variable, what about
> another insert in
> another table. would this cause a problem?
>
> thanks
> ----- Original Message -----
> From: Dave Watts <[EMAIL PROTECTED]>
> Subject: RE: Avoiding using the MAX function
>
>
> > CREATE PROC insItem
> >
> > @Item_Name varchar(30),
> > @Item_Desc varchar(255)
> >
> > AS
> >
> > INSERT INTO Item
> > (Item_Name,
> > Item_Desc)
> > VALUES
> > (@Item_Name,
> > @Item_Desc)
> > SELECT ID = @@IDENTITY
> >
> > You could then reference the ID field in the resulting recordset.
>
>
> --------------------------------------------------------------
> ----------------
> Archives: http://www.eGroups.com/list/cf-talk
> To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
Archives: http://www.eGroups.com/list/cf-talk
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
