Oops...accidentally replied to Steven directly. ---------- Forwarded message ---------- From: Larry Meadors <[EMAIL PROTECTED]> Date: Jun 28, 2005 9:15 AM Subject: Re: Post Generated Keys To: "Mitchell, Steven C" <[EMAIL PROTECTED]>
Yes, that is possible in an environment where updates happen simultaneously if the driver does not make those calls local to the connection/transaction. I would be (unpleasantly) suprised if Oracle's driver fell into that category. I know that DB2 does make them local to the transaction. I am a fan of pre-generated keys for that very reason. :-) Larry On 6/28/05, Mitchell, Steven C <[EMAIL PROTECTED]> wrote: > Larry, > > Your suggestion of using sequence.currval works great. I just left the > ID column off of the insert statement. I assume there is some risk of > getting the wrong ID during simultaneous updates. I'll get triggers > turned off as soon as we cut over to the new application and go back to > pre-generated keys with sequence.nextval. > > Thanks. > Steve > -----Original Message----- > From: Larry Meadors [mailto:[EMAIL PROTECTED] > Sent: Monday, June 27, 2005 2:51 PM > To: [email protected] > Subject: Re: Post Generated Keys > > > Use sequence.currval instead. > > On 6/27/05, Mitchell, Steven C <[EMAIL PROTECTED]> wrote: > > > > I'm converting an Oracle application to iBatis. I discovered that the > > > database is using triggers to generate ids (I was using > > sequence.nextval and my ids were off by one). The documentation says > > iBatis supports both pre and post generated keys. Is that true for > > Oracle too? The post-generated example is for SQL Server @@IDENTITY. > > > I would have the DBAs turn off the triggers, but I have to run in > > parallel for some time. Am I stuck doing a select on some other key > > immediately following the insert to find out the generated ID? >
