FAQ
There is a coder here who has a lot of code that goes like this:
PROCEDURE fsf IS
-- declare some stuff
BEGIN

INSERT into a table
EXCEPTION

WHEN DUP_VAL_ON_INDEX THEN

NULL; -- or it actually performs an update
END fsf;

It is quite a legitimate thing that there could be duplicates because
of the fact that data is being read out of files, etc. I do not know if
its the norm or the unusual.

If I was coding it and I new there was a possibility of duplicates and
I either did not want to insert it or wanted to update the record instead
I would check the database first via a SELECT and then base my
code on what got returned.

Is one really any better then the other. I am kind of against letting
ORA errors being raised on purpose. Its one thing if something goes
wrong but this is expected. Which would be harder on the database?
They both have to get the data from disk (or memory as the case may be).

Kimberly Smith
EDS

Fujitsu/GMD
21015 SE Stark St
Gresham, OR
97030
Phone: (503) 669-6050
Fax : (503) 669-5705

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Kimberly Smith
INET: kimberly.smith_at_gmd.fujitsu.com

Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------

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).

Search Discussions

  • Smith, Ron L. at Feb 6, 2001 at 9:49 pm
    If you did a select on every row you were adding and seldom got a hit you
    would be wasting a lot of time and resources. The way the procedure is
    coded, no extra processing is required.

    -----Original Message-----
    Sent: Tuesday, February 06, 2001 3:18 PM
    To: Multiple recipients of list ORACLE-L

    There is a coder here who has a lot of code that goes like this:
    PROCEDURE fsf IS
    -- declare some stuff
    BEGIN

    INSERT into a table
    EXCEPTION

    WHEN DUP_VAL_ON_INDEX THEN

    NULL; -- or it actually performs an update
    END fsf;

    It is quite a legitimate thing that there could be duplicates because
    of the fact that data is being read out of files, etc. I do not know if
    its the norm or the unusual.

    If I was coding it and I new there was a possibility of duplicates and
    I either did not want to insert it or wanted to update the record instead
    I would check the database first via a SELECT and then base my
    code on what got returned.

    Is one really any better then the other. I am kind of against letting
    ORA errors being raised on purpose. Its one thing if something goes
    wrong but this is expected. Which would be harder on the database?
    They both have to get the data from disk (or memory as the case may be).

    Kimberly Smith
    EDS

    Fujitsu/GMD
    21015 SE Stark St
    Gresham, OR
    97030
    Phone: (503) 669-6050
    Fax : (503) 669-5705

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Kimberly Smith
    INET: kimberly.smith_at_gmd.fujitsu.com

    Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
    San Diego, California -- Public Internet access / Mailing Lists
    --------------------------------------------------------------------

    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.com
    --
    Author: Smith, Ron L.
    INET: rlsmith_at_kmg.com

    Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
    San Diego, California -- Public Internet access / Mailing Lists
    --------------------------------------------------------------------

    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).
  • Dasko, Dan at Feb 6, 2001 at 10:10 pm
    Your way selects everytime. The coder's way only deals with it when it
    happens. If there are a lot of duplicates, your way is smarter and probably
    quicker. If duplicates are rare, coder's way is quicker.

    Dan

    -----Original Message-----
    Sent: Tuesday, February 06, 2001 4:18 PM
    To: Multiple recipients of list ORACLE-L

    There is a coder here who has a lot of code that goes like this:
    PROCEDURE fsf IS
    -- declare some stuff
    BEGIN

    INSERT into a table
    EXCEPTION

    WHEN DUP_VAL_ON_INDEX THEN

    NULL; -- or it actually performs an update
    END fsf;

    It is quite a legitimate thing that there could be duplicates because
    of the fact that data is being read out of files, etc. I do not know if
    its the norm or the unusual.

    If I was coding it and I new there was a possibility of duplicates and
    I either did not want to insert it or wanted to update the record instead
    I would check the database first via a SELECT and then base my
    code on what got returned.

    Is one really any better then the other. I am kind of against letting
    ORA errors being raised on purpose. Its one thing if something goes
    wrong but this is expected. Which would be harder on the database?
    They both have to get the data from disk (or memory as the case may be).

    Kimberly Smith
    EDS

    Fujitsu/GMD
    21015 SE Stark St
    Gresham, OR
    97030
    Phone: (503) 669-6050
    Fax : (503) 669-5705

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Kimberly Smith
    INET: kimberly.smith_at_gmd.fujitsu.com

    Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
    San Diego, California -- Public Internet access / Mailing Lists
    --------------------------------------------------------------------

    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 message has been checked for all known viruses by UUNET delivered
    through the MessageLabs Virus Control Centre. For further information visit
    http://www.uk.uu.net/products/security/virus/
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Dasko, Dan
    INET: Dan.Dasko_at_cdicorp.com

    Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
    San Diego, California -- Public Internet access / Mailing Lists
    --------------------------------------------------------------------

    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).
  • MTPConsulting_at_aol.com at Feb 7, 2001 at 2:59 am
    I'd do it based on which is more likely to succeed. That will give you the
    best performance. Also, I think there's some new DML in Oracle9i that
    combines insert/update into one statement.

    Marc Perkowitz
    MTP Systems Consulting

    In a message dated 2/6/2001 3:43:09 PM Central Standard Time,
    kimberly.smith_at_gmd.fujitsu.com writes:

    << There is a coder here who has a lot of code that goes like this:
    PROCEDURE fsf IS

    declare some stuff
    BEGIN

    INSERT into a table
    EXCEPTION

    WHEN DUP_VAL_ON_INDEX THEN

    NULL; -- or it actually performs an update
    END fsf;

    It is quite a legitimate thing that there could be duplicates because
    of the fact that data is being read out of files, etc. I do not know if
    its the norm or the unusual.


    If I was coding it and I new there was a possibility of duplicates and
    I either did not want to insert it or wanted to update the record instead
    I would check the database first via a SELECT and then base my
    code on what got returned.


    Is one really any better then the other. I am kind of against letting
    ORA errors being raised on purpose. Its one thing if something goes
    wrong but this is expected. Which would be harder on the database?
    They both have to get the data from disk (or memory as the case may be).


    Kimberly Smith
    EDS

    Fujitsu/GMD
    21015 SE Stark St
    Gresham, OR
    97030
    Phone: (503) 669-6050
    Fax : (503) 669-5705
    >>

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: MTPConsulting_at_aol.com

    Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
    San Diego, California -- Public Internet access / Mailing Lists
    --------------------------------------------------------------------
    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).

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedFeb 6, '01 at 9:15p
activeFeb 7, '01 at 2:59a
posts4
users4
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase