Re: SQL question

Try to separate the employee-lookup-and-create into separate procedure. In the procedure, if the lookup does not find the employee, then call another procedure with an autonomous transaction to create the employee, that way the employee creation does not become part of the master transaction, is lightning quick, and greatly reduces the possibility of two processes creating the exact same employee record. Not guaranteed, but in 99.99% of the cases, this should work fine.

Is this a packaged application, or can you make changes to the code that is invoked ?

Ferenc Mantfeld
Dreaming costs you nothing. Not dreaming costs you everything. ----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Tuesday, February 25, 2003 7:54 AM

> Sorry, I guess I could have been a little more clear.
>
> Another example:
>
> Table Employee:
> Emp_id number primary key -- generated with a sequence
> Emp_name varchar2(20) unique
>
> Table Employee_log:
> Emp_id number primary key
> Time_stamp date primary key
> Emp_stats varchar2(50)
>
> A process receives the employee name, and other information that needs to
be
> stored in the table employee_log. The process needs to retrieve the
emp_id
> from the employee table, so it does a lookup. If the employee exists, the
> emp_id is retrieved and the information is then inserted into the
> employee_log table. If the employee does not currently exist, a new
> employee is added to the table employee.
>
> We run into problems when we have many concurrent processes running and
more
> than one process receives the same employee name. They both do a lookup
and
> they both conclude the employee does not exist. Thus, they both try and
do
> an insert into the employee table. One will succeed and the other will
> fail.
>
> Is there away to avoid this scenario?
>
> I hope I made this a little clearer.
>
> Thanks,
>
> Rick Stephenson
>
> -----Original Message-----
> Sent: Monday, February 24, 2003 1:05 PM
> To: Multiple recipients of list ORACLE-L
>
> Rick - What about selecting the primary key for your table from a
sequence?
> Oracle will ensure each session receives a unique number.
>
> What is your overall goal?
>
>
>
> Dennis Williams
> DBA, 40%OCP, 100% DBA
> Lifetouch, Inc.
> dwilliams_at_lifetouch.com
>
> -----Original Message-----
> Sent: Monday, February 24, 2003 1:50 PM
> To: Multiple recipients of list ORACLE-L
>
>
>
> OS: Solaris 2.8
>
> Database: Oracle 9.2.0.2
>
>
>
> Situation in chronological order
>
> Connection A: select * from table A where id = 1; Result: no rows
returned
> -- This means I need to insert the row, as it does not exists yet.
>
> Connection B: select * from table A where id = 1; Result: no rows
returned
> -- This means I need to insert the row, as it does not exists yet.
>
> Connection A: insert into table A(id) values = 1; Result: 1 row inserted
>
> Connection B: insert into table A(id) values = 1; Result: Unique
constraint
> violated -- This is the problem. How do I avoid this happening?
>
>
>
> Question: How can I force connection B to wait for connection A to insert
> the new row before it does the select?
>
>
>
> If I were updating the row, I could use the "for update" clause to force
the
> wait. Is there a clean way to do that for an insert?
>
>
>
> Thanks for your help,
>
>
>
> Rick Stephenson
>
>
>
>
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to which they are
addressed.
> This message contains confidential information and is intended only for
the
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
delete
> this e-mail from your system. If you are not the intended recipient you
are
> notified that disclosing, copying, forwarding or otherwise distributing or
> taking any action in reliance on the contents of this information is
> strictly prohibited.
>
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: DENNIS WILLIAMS
> INET: DWILLIAMS_at_LIFETOUCH.COM
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to which they are
addressed.
> This message contains confidential information and is intended only for
the
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
delete
> this e-mail from your system. If you are not the intended recipient you
are
> notified that disclosing, copying, forwarding or otherwise distributing or
> taking any action in reliance on the contents of this information is
> strictly prohibited.
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Rick Stephenson
> INET: RStephenson_at_Ovid.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Ferenc Mantfeld
  INET: mantfield_at_connexus.net.au

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).